Come posso evitare un maggiore consumo di memoria da parte del browser e un peggioramento delle prestazioni quando si gestiscono molti record?

2

Nella mia applicazione Web MVC 5 ci sono molte istanze in cui gli utenti richiedono di visualizzare migliaia di record all'interno delle griglie, ora sono riuscito a risolvere molti problemi relativi alle prestazioni utilizzando quanto segue:

  • Caricamento dati lento.
  • Compressione JSON.
  • Caricamento Ajax Progrssive.
  • DOM virtuale
  • Recupera solo le colonne più importanti.

Che tutto funziona bene finora, il server difficilmente riesce a restituire e serializzare i dati in JSON, il mio problema è dal lato client, che è principalmente:

  • Più dati vengono caricati nella griglia più memoria viene consumata dal browser, per circa 10.000 record consumerà circa 1,5 GB.
  • La perfomance del browser tende a peggiorare per tutte le schede aperte mentre le prestazioni della macchina funzionante sono normali e non degradate.

Sto caricando tutti i record utilizzando il caricamento AJAX progressivo in background e non scorrendo, la ragione per cui sto facendo questo è perché gli utenti si lamenteranno dei filtri e dell'ordinamento applicati ai record caricati ma non a tutti i record.

Ho pensato invece all'ordinamento e al filtraggio dei server, ma questo non sarebbe ancora adatto per lavorare con altre funzionalità di manipolazione dei dati come il raggruppamento.

Non c'è modo di poter ancora ritirare questo numero di record ma evitare i due problemi sopra elencati?

La griglia che sto attualmente utilizzando è Tabulator

Sarebbe bello sapere come posso indagare su cosa sta occupando così tanta memoria, sono i dati che vengono caricati nel DOM o sono oggetti JS ecc.

    
posta Abs 21.07.2018 - 17:37
fonte

2 risposte

2

L'altra risposta inviata è valida. La rimozione delle righe nascoste dal DOM ti offrirà prestazioni migliori. Tuttavia, non affronta il problema di fondo che stai trasmettendo tutti i dati al browser prima di applicare qualsiasi filtro ad esso; che crea molti problemi tangenziali come l'uso eccessivo della larghezza di banda e tempi di risposta più elevati per ottenere l'elenco di elementi.

because users will complain about filters and sorting being applied to loaded records but not to all records

In altre parole, se si restituisce la pagina 2 (articoli da 101 a 200) e l'utente ha chiesto di filtrare i nomi contenenti "pippo", si applica tale filtro a quei 100 articoli; invece di applicare il filtro sul database e quindi di mostrare la pagina 2 del set risultante?

Questo è il tuo problema. I filtri devono essere applicati prima dell'impaginazione. Se si esegue il filtraggio solo sulla pagina Web dopo che tutti gli elementi sono stati caricati, l'impaginazione deve avvenire logicamente anche nel browser.

Potrebbero esistere soluzioni alternative per il tuo attuale problema di prestazioni (come la rimozione degli elementi filtrati dal DOM), ma quando la dimensione dei dati aumenta, il problema relativo alle prestazioni (e alla larghezza di banda) verrà visualizzato di nuovo in una forma diversa (una che non può essere risolto rimuovendo cose dal DOM).
L'unico modo per risolvere in modo sostenibile questo è non passare tutti i dati alla pagina web .

I thought about server sorting and filtering instead but that would just is still not suitable for working with other data manipulation functionality such as grouping.

Non sto seguendo la tua spiegazione qui. Il raggruppamento è solo un altro passo sulla strada per ottenere l'output desiderato. Esiste una logica sequenziale sul recupero dei dati:

  • Filtro
  • gruppo
  • Ordine
  • Seleziona
  • Impagina

Non tutti i passaggi sono necessari, ma l'ordine in cui eseguirli è solitamente lo stesso (salvo alcuni casi marginali, ad esempio il filtraggio di gruppi complessi - a quel punto il raggruppamento diventa un dato e non un'opzione secondo la descrizione)

Quello che stai facendo ora è smorzare il tuo back-end e assumersi tutte le responsabilità nel frontend, che non è semplicemente un buon design. Il back-end (in particolare un'archiviazione dei dati basata su SQL) è adattato per un efficiente recupero dei dati.

Non vedo alcun argomento ragionevole per trasferire tutta questa responsabilità a un frontend che è intrinsecamente meno capace di gestire grandi raccolte di dati e di eseguire costose operazioni di dati. Sconvolge tutte le parti coinvolte:

  • La rete interna tra database e backend invia più dati di quanti l'utente sia effettivamente interessato.
  • Il back-end deve istanziare più dati di quanti l'utente sia effettivamente interessato.
  • La rete esterna tra back-end e frontend invia più dati di quanti l'utente sia effettivamente interessato.
  • Il frontend deve gestire molti più dati di quanti l'utente sia effettivamente interessato.

Stai facendo perdite nel carico di rete, nell'uso della larghezza di banda, nelle prestazioni delle applicazioni e nell'esperienza utente, il tutto a vantaggio di non dover sviluppare un metodo per filtrare / raggruppare / ordinare / impaginare dati sul back-end?

I professionisti non superano gli svantaggi qui.

[From a comment] there are client side functions that are driven by the users interaction that should take all data into account

Stai mettendo il carro davanti al cavallo qui. Li stai già chiamando "funzione lato client" che è la fonte del problema. Se dovessi impostare un'interazione tra il frontend e il backend in modo che il backend possa gestire la manipolazione dei dati necessaria, allora non sono più "funzioni lato client".

Non riesco a pensare a nessuna manipolazione di dati che può essere fatta solo lato client e non lato server. Mi interessa ascoltare un esempio di queste "funzioni lato client".

    
risposta data 23.07.2018 - 08:47
fonte
3

La migliore libreria che ho usato per visualizzare tonnellate di dati in un formato di griglia è SlickGrid .

Ecco un buon esempio di una griglia con 500.000 righe che dimostra le prestazioni.

Esempio: 500.000 righe in DataView

In poche parole, una volta superata una certa soglia (forse 10.000 righe), non puoi permetterti di avere tutte le righe della griglia visualizzate nel DOM. Ogni elemento DOM comprenderà più istanze di oggetti e occuperà una certa quantità di memoria.

Le librerie come SlickGrid aggirano questo aspetto rendendo solo le righe visibili. Qualsiasi riga non visibile all'utente viene rimossa dal DOM. Ciò comporta enormi guadagni in termini di prestazioni.

Se si utilizza il codice, si avrà un'idea di come questo viene realizzato. Vedi link come esempio.

    
risposta data 21.07.2018 - 22:04
fonte

Leggi altre domande sui tag