Quali sono le informazioni giuste da memorizzare nella cache? Qual è un buon tempo di caricamento della pagina?

Question

Sto sviluppando un sito di social network.

E pensando alla scalabilità sin dal primo giorno del progetto, ho messo a punto il sito e le query al meglio delle mie capacità.

Tuttavia; Alcune pagine sono molto ricche di dati e non sono sicuro che si stiano caricando il più velocemente possibile, quindi stavo pensando di implementare una soluzione di cache distribuita.

Ma non sono sicuro di cosa dovrei memorizzare nella cache e non nella cache. O se i tempi di caricamento della pagina corrente di 1 secondo sono buoni o cattivi.

La query più pesante sta catturando le informazioni sui membri, questa query ottiene tutte le informazioni sui membri e qualsiasi cosa ad essi correlata, come nel caso di questo sito i loro obiettivi, voci sul tipo di blog, incoraggiamenti, foto, aggiornamenti di stato (come Twitter), informazioni sul blog (per incrociando le loro voci) ecc. ecc.

Comunque, dovrei memorizzare queste informazioni nella cache? E pensi che i tempi di caricamento di una seconda pagina siano ragionevolmente veloci? Alcune pagine sono meno di un secondo tra 4-6 decimi di secondo.

Answer 1

Se possibile, implementerei la memorizzazione nella cache su ogni singolo livello dell'applicazione.

È possibile memorizzare nella cache le pagine al livello più alto, gli oggetti a livello del codice e assicurarsi che il database memorizzi correttamente le query e i dati chiave al livello più basso.

In termini di COSA è necessario memorizzare nella cache, tutti gli oggetti a cui si accederà in modo ripetuto dovrebbero essere memorizzati nella cache, in particolare quelli che è improbabile che cambino molto spesso. È quindi possibile ripristinare la cache di quell'oggetto solo quando viene modificato. (Prestare attenzione alla memorizzazione nella cache di oggetti che vengono frequentemente aggiornati come un ciclo costante di sostituzione della cache su quasi ogni carico peggiorerà le prestazioni anziché migliorarle)

Per misurare le prestazioni, non vedrei quanto tempo impiega una singola pagina a caricarsi, ma cerco su Google alcuni strumenti di misurazione delle prestazioni in quanto è necessario testare la velocità con cui ciascuna pagina funziona sotto pressione. La tua pagina di informazioni utente potrebbe non essere la destinazione di memorizzazione nella cache più grande se, ad esempio, è raramente accessibile. Dovresti concentrarti sulle pagine più utilizzate.

Answer 2

La risposta tipica è:

• Informazioni sulla cache che vengono aggiornate raramente.
• Non memorizzare nella cache ciò che cambia di frequente.

Nel tuo caso, puoi memorizzare nella cache tutto in file flat (ad esempio un file per utente) e distruggere un file di cache utente ogni volta che qualcosa viene aggiornato dal corrispondente. Se il file cache non esiste, lo si crea prima di visualizzare il contenuto associato.

Ora sul tempo di caricamento (che può essere molto diverso a seconda della posizione dell'utente), ecco alcuni numeri informativi da un forum PHP di un sito di gioco:

• Tempo di caricamento JS: 0,274
• Conteggio query: 15
• Tempo di caricamento PHP: 0,0524
• Utilizzo della memoria: 1,013 MB

E questo è considerato dalla comunità come una buona esperienza. Ma è terribilmente soggettivo.

Answer 3

La domanda di caricamento della pagina era già stata posta:

Che cosa è considerato un buon tempo di risposta per un'applicazione web dinamica e personalizzata?

In termini di memorizzazione nella cache, è necessario misurare la quantità di tempo che verrebbe impiegata a caricare i dati ogni volta rispetto al caricamento dalla cache. Più grande è la cache, meno efficace diventa. Quindi non vuoi caricare troppi dati nella cache. Quello che usiamo qui è una cache rolling, con i dati utilizzati meno di recente che vengono eliminati una volta raggiunto il limite della dimensione della cache. Quindi ottimizzare il limite in base ai risultati effettivi delle prestazioni.

Answer 4

Per i dati specifici del profilo utente, archiviare il più possibile in un ticket / cookie FormsAuth. Gli elementi specifici dell'utente nella cache (HttpContext.Current.Cache) richiedono X risorse sul server per utente, lo stesso della sessione (ma con meno mal di testa). Se riesci a scaricare il più possibile nel Ticket o cookie dell'utente (come 4K), aiuterai davvero le prestazioni dei tuoi server durante il ridimensionamento.

Dovresti solo recuperare le informazioni necessarie alla pagina. Ad esempio, se stai caricando i dati del blog, NON caricare foto. È più lavoro, sì, ma se vuoi ridimensionare dovrai analizzare le esigenze di ogni pagina.

Assicurarsi di comprendere le differenze tra la memorizzazione nella cache delle query del database (riutilizzo del piano di esecuzione), la memorizzazione nella cache degli oggetti (Httpcontext.Cache) e la memorizzazione nella cache delle pagine (Response.Headers [Scade]).

Answer 5

Guru del web design Vincent Flanders suggerisce che qualcosa di più di 4 secondi è troppo lungo per essere caricato su una pagina web . Penso che questa sia una regola empirica piuttosto buona.

Per quanto riguarda la memorizzazione nella cache o altre ottimizzazioni delle prestazioni, ti consiglio di eseguire alcuni test delle prestazioni. Esistono numerosi kit di test delle prestazioni disponibili sul mercato. I test mostreranno dove si trovano le aree problematiche. Non ha senso aggiungere la logica di memorizzazione nella cache a qualcosa che già funziona bene. D'altra parte, potrebbero verificarsi problemi di prestazioni in cui non ci si potrebbe aspettare, con dati che potrebbero non essere stati considerati nella cache.

Qualcosa che ho trovato anche con il test delle prestazioni è che può trovare punti nel tuo codice in cui si verificano deadlock o dove potrebbero essere utili semplici ottimizzazioni del database. Forse l'aggiunta di un indice a una tabella velocizzerà una pagina invece di aggiungere un sacco di logica di cache.

Lo terrei semplice e rifletterò solo per le prestazioni dove è necessario.

Inoltre, prova presto e prova spesso. So che molte persone dicono di considerare le prestazioni per ultime, ma puoi davvero codificarti in un angolo se almeno non inizi a considerarle all'inizio del ciclo di vita dello sviluppo.

Answer 6

Alcune ricerche suggeriscono che l'applicazione interattiva deve fornire un feedback entro 250 ms per non far credere all'utente che sia bloccato o che l'operazione non è riuscita. Tuttavia, il livello di accettazione sul Web è leggermente più elevato e, di solito, il browser web fornisce feedback sul caricamento di una nuova pagina. Con AJAX devi fare attenzione a fornire una sorta di feedback, perché il browser non mostrerà cosa sta succedendo.