Memorizzazione nella cache dei dati del database durante la sessione: ottenere il giusto equilibrio

Question

Se si memorizzano nella cache i dati dal proprio database nella sessione ASP.NET, si accelereranno le successive richieste di tali dati (nota: a seconda del costo di serializzazione / deserializzazione dei dati in questione), a spese del carico di memoria in IIS.

(OK, questa è probabilmente una semplificazione della realtà della situazione - sentiti libero di correggere o affinare la mia affermazione sopra)

Usi delle regole (semplici regole empiriche o altro) per decidere quando è opportuno memorizzare nella cache in Session?

Aggiornamento

Può usare la sessione per archiviare dati di sola lettura senza ragionamento molto ben studiato semplicemente essere considerato un altro caso di Ottimizzazione precoce ? (e quindi, male)

Answer 1

Tieni presente la memorizzazione nella cache della sessione se usi la modalità InProc, stai limitando la tua scalabilità a meno che il tuo codice non torni nel DB quando la sessione è vuota. Sarai costretto a utilizzare un singolo server o bloccare l'utente su un determinato server.

Se si utilizza Session State Server questo non si applica e se si utilizza SQL per archiviare lo stato della sessione, l'utilizzo della sessione per la memorizzazione nella cache è inutile.

Modifica

Qualsiasi consiglio su questo argomento è soggetto al tuo ambiente specifico. Come hai affermato, una query sql molto complessa potrebbe trarre vantaggio dalla memorizzazione nella cache anche quando si utilizza lo stato della sessione SQL. Penso che la cosa più importante sia innanzitutto far sì che l'applicazione esegua le funzioni e soddisfi i requisiti aziendali. Quindi tornare indietro e testare e ottimizzare l'applicazione per gestire il carico previsto.

Modifica 2

In base al tuo aggiornamento no, non credo sia vero. In una delle mie applicazioni ASP.Net sto usando lo stato della sessione per memorizzare un modello di oggetto complesso che l'utente sta quindi manipolando e modificando. Stiamo usando AJAX e quindi abbiamo molte brevi comunicazioni al server mentre l'utente aggiorna l'oggetto. Mantenere l'oggetto in sessione è stato fatto come una comodità. L'oggetto esegue molti calcoli personalizzati per generare diversi punti di dati, quindi farlo sul server era l'ideale invece di provare a replicare il codice nel servr e in javascript. Inoltre, tenerlo in sessione ci consente di avere una funzione di annullamento molto facilmente.

E sì, so che abbiamo sacrificato la scalabilità, ma accolgo con favore il giorno in cui mi siedo con il mio capo e spiego che abbiamo un problema perché abbiamo troppi utenti (e so che lo farebbe anche lui).

Quindi penso che la domanda sia: perché stai memorizzando i dati in sessione per motivi di convenienza e per fornire accesso ai dati transitori mentre l'utente ha effettuato l'accesso? È diverso quindi memorizzarlo lì per la memorizzazione nella cache. Una cosa da ricordare con la memorizzazione nella cache è come hai intenzione di svuotare la cache? Come si annulla? Non lo stato della sessione è stato creato per gestire questo.

Modifica 3

Ritornando a leggere bene solo i dati, specifici dell'utente, costosi da caricare dal DB, andare avanti cache nella sessione. Puoi scrivere il tuo codice, quindi se non è in sessione, premi il DB. Tieni una piccola classe di supporto che fa ciò dandoti dalla tua app web che stai usando anche la sessione e dovresti essere bravo. La cosa bella di sapere dove lo memorizzi dal tuo web se ti accorgi che hai dei problemi hai solo un posto dove cambiarlo.

Answer 2

Dato che è molto difficile garantire che i dati in una sessione vengano chiariti in un lasso di tempo ragionevole, sarei molto diffidente nel guadagnare qualcosa di più dell'intero dispari lì. Quando si arriva su larga scala, si verificano problemi di memoria o si verificano errori di timeout della sessione per tutti gli utenti. Ricorda che a differenza delle sessioni di oggetti cache non vengono uccisi quando la memoria è insufficiente.

Inoltre, come dice Josh, se si va su più server e è necessario utilizzare un database o un server dello stato della sessione, l'oggetto della sessione dovrà essere serializzabile. In questo caso è probabile che il costo di serializzare e de-serializzare sia peggiore del costo di una query ben ottimizzata.