Out of proc SessionStazione gestione memoria

Question

Stiamo utilizzando un servizio stato sessione out-of-proc Stato sessione ASP.Net. Sappiamo di avere problemi con questo dato che è stato abusato in passato, troppo spesso archiviato nello stato della sessione troppo spesso, quindi eravamo in procinto di passare a un sistema più scalabile.

Nel frattempo, però, che stiamo cercando di ottenere le nostre teste intorno a come un servizio di stato sessione gestisce la memoria e quali limiti dobbiamo. Ma none di the Microsoft docs sembra entrare nei dettagli.

In particolare vorrei sapere:

• Quali sono i limiti a quanto "lo standard" fuori proc servizio di stato sessione (installato con IIS nella console di gestione di Windows) in grado di memorizzare? (x64)
• Esiste un limite per utente?

da servizio standard, voglio dire questo:

Answer 1

non c'è limite al di là del computer che ospita il servizio. Se ha 16 GB di RAM, supponendo che alcuni concerti siano usati per altri processi/OS/ecc., Ci saranno circa 13 GB di memoria disponibile per i dati di sessione. I dati non sono persistenti su disco, quindi i dati esistono sempre solo nella RAM/memoria; questo è il motivo per cui quando si riavvia il servizio tutte le sessioni sono esaurite. La memoria è volatile e funziona come un disco RAM.

Se si raggiungono i limiti di memoria della macchina che ospita il servizio di stato della sessione, si memorizzano troppi dati per utente o si hanno troppi utenti che memorizzano un po 'di dati. Sei già sulla strada giusta mentre il passo successivo è passare a un fornitore di stato della sessione distribuito per scalare correttamente. Ciò è spesso ottenuto tramite un sistema di caching distribuito fornito con un provider di stato di sessione o scrivendo il proprio provider contro tale sistema.

Non esiste un limite per utente sui dati, ma si noti che la comunicazione fuori processo avviene sempre tramite la serializzazione. Pertanto, esiste un limite pratico in quanto la serializzazione/deserializzazione di una serie di dati utente per richiesta sarà molto lenta, indipendentemente dal modo in cui ci si avvicina.