Prestazioni su pagine Web altamente filtrabili

0

Nella nostra applicazione abbiamo una pagina dove elenchiamo le nostre entità con molte opzioni per filtrare e cercare. Nel corso del tempo questa pagina è diventata più lenta e lenta soprattutto per i set di dati di grandi dimensioni, quindi abbiamo pensato a come migliorare le prestazioni. Ho due idee:

  1. Utilizza un servizio come Elasticsearch creato per problemi come questi (anche se non vorremmo introdurre un'ulteriore dipendenza)
  2. Implementa il caching corretto

Tuttavia il caching fornisce solo un aumento della velocità se la stessa risorsa viene richiesta due o più volte. In una pagina in cui i record possono essere filtrati in molti modi diversi, tuttavia non credo che l'accelerazione del caching verrà utilizzata spesso a causa della grande varietà con cui i dati verranno filtrati e presentati. E anche se un utente sta richiedendo la pagina utilizzando filtri identici come qualcuno (o se stesso) prima, c'è un'alta probabilità che fino ad allora i dati siano cambiati e quindi la cache non è più valida.

Mi sbaglio nella mia ipotesi? Come sviluppare pagine come queste in modo performante?

Grazie

EDIT:

Ecco qualche informazione in più:

Utilizziamo Ruby on Rails, un database MySQL e l'ORM ActiveRecord. Per una richiesta della pagina citata recuperiamo i dati da circa 10 diverse tabelle di database contenenti ciascuna da 5000 a 5.000.000 di voci. Raramente c'è una ricerca basata sul testo, la maggior parte delle volte cerchiamo filtrando le chiavi esterne come in "Dammi tutti i dipendenti della società XY". Il nostro database è correttamente indicizzato, su questo abbiamo preso molta cura. Ho inoltre effettuato un'analisi approfondita delle query utilizzando la funzionalità MySQL EXPLAIN. Il filtraggio e la preparazione dei dati e delle meta informazioni (ad esempio il conteggio dei record) avviene sul lato server.

Il sito funziona male perché visualizza molte informazioni e quindi deve eseguire diverse query pesanti. Come esempio per una query pesante:

Ottieni tutte le stanze per un certo edificio dove almeno una persona è seduta. Per ottenere questi dati dobbiamo prima recuperare tutte le persone di questo edificio e poi ottenere il conteggio delle persone per ogni stanza per vedere se c'è almeno una persona al suo interno.

    
posta Chris 26.04.2018 - 14:52
fonte

3 risposte

2

Innanzitutto, la memorizzazione nella cache è difficile . Puoi ottenere alcuni incredibili miglioramenti delle prestazioni quando è implementato correttamente e il rapporto di riscontri cache è abbastanza alto, ma dovrai digrignare un sacco di denti per arrivarci.

Consideralo come "solo un altro problema di ottimizzazione" e procedi di conseguenza.

Questo significa che non indovinare . Trova un modo per misurare le prestazioni della tua applicazione e dimostrare in modo definitivo quali parti stanno causando dolore. Poiché (presumo) si tratta di un'app Web, comincerei col colpire F12 e usare il profiler.

Domande iniziali da porre:

  • Il browser web impiega molto tempo per elaborare i dati una volta ricevuti?
  • Ci vuole troppo tempo per ottenere dati nel browser?
  • Il server impiega troppo tempo per ottenere i dati?

Le risposte a queste domande determineranno la tua prossima serie di domande che determineranno la prossima (una così via).

    
risposta data 26.04.2018 - 15:28
fonte
0

Inserisci un indice nel tuo database.

I database sono efficaci nella ricerca e nel filtraggio, se dispongono di indici appropriati. Quindi scrivi le query che utilizzano questi indici. Accedi e analizza le query lente per scoprire perché sono lenti. Senza un indice, la ricerca deve filtrare ogni elemento, che diventa progressivamente più lento man mano che vengono aggiunti altri elementi.

Se il carico sul server DB è troppo alto, considerare se il DB può essere replicato o messo a punto. Ciò ti consentirà di distribuire il carico su più server. Nota che il sharding non è di aiuto se tutti gli elementi comunemente richiesti sono su un nodo.

Sia che utilizzi un database speciale come Elastic Search o semplicemente usi le funzionalità che MySQL ha già da offrire non importa molto qui, se hai un modello dati adeguato. Per esempio. se è necessaria la ricerca full-text, un database specializzato potrebbe essere più appropriato.

La cache da sola non renderà tutte le tue query veloci. Può semplicemente ridurre il carico sul tuo DB. Se raccogli statistiche per le tue query, potresti vedere che alcune richieste sono davvero molto comuni (come gli articoli in una pagina di destinazione). Questa potrebbe essere una soluzione sufficiente per il tuo problema, se le tue misure lo indicano. Ma la memorizzazione nella cache non accelera effettivamente ogni singola query.

Si noti che in teoria è possibile scrivere codice intelligente che filtra i dati già memorizzati nella cache. Ma a quel punto, stai reinventando un database. Ci sono probabilmente bug. È molto più semplice utilizzare la cosa reale, a meno che la creazione di un nuovo motore di database non sia il prodotto che stai offrendo.

    
risposta data 26.04.2018 - 15:34
fonte
0

Il punto è qui:

Nessuno è in grado di darti un consiglio adeguato senza vedere il tuo sistema.

Ovviamente potresti ricevere consigli generici come:

  • usa la cache
  • usa gli indici
  • usa lo sharding
  • usa la denormalizzazione

ecc. Tutto si riduce a a) »misura« eb »» organizza meglio «i tuoi dati.

Che non è tutto sbagliato. Ma da quello che hai scritto, il tuo sistema è già ottimizzato, quindi non aiuta.

Our database is properly indexed, about this we took great care.

Forse dai un'occhiata a Pilosa . Sembra che la tua applicazione sia un caso d'uso per questo.

Altro sfondo:

risposta data 26.04.2018 - 16:08
fonte

Leggi altre domande sui tag