Consentire la sessione in una Web farm? StateServer è abbastanza buono?

Question

Prima di tutto per darti un po 'di background sull'ambiente attuale. Abbiamo un numero di applicazioni ASP.NET, che utilizzano tutte le sessioni per determinati aspetti. Siamo "Load Balanced" su più server a causa dei livelli di traffico, tuttavia, il bilanciamento del carico è impostato per utilizzare "Sticky Session" poiché attualmente tutte le applicazioni Web sono impostate per utilizzare "InProc" per lo stato di sessione.

Stiamo cercando di rimuovere la configurazione di "Sticky Sessions" sul nostro servizio di bilanciamento del carico, poiché i server che caricano il traffico possono sovraccaricarsi. Vogliamo andare con un approccio più equilibrato, ma dobbiamo essere in grado di utilizzare la sessione.

So che SqlServer per lo stato della sessione funzionerà, ma per ragioni indipendenti dalla nostra volontà, non possiamo utilizzare SqlServer per memorizzare il nostro stato. Nella ricerca sembra che StateServer sia la nostra migliore scommessa. Abbiamo un server aggiuntivo, con un sacco di memoria seduti intorno. Questo server potrebbe essere il nostro StateServer per l'intero Web Cluster. Vogliamo solo sapere le seguenti cose.

1.) Oltre a eventuali problemi di serializzazione con il passaggio da InProc a StateServer, ci sono problemi noti con la perdita di oggetti di sessione o la generazione di errori con l'ambiente sopra elencato?

2.) Oltre al singolo punto di errore, e prestazioni leggermente più lente ci sono altri trucchi che dobbiamo sapere con l'uso di StateServer.

3.) Esistono metriche che mostrano le differenze di prestazioni tra i tre tipi di memoria di stato?

Answer 1

Ecco una FAQ decente su asp.net Stato: http://www.eggheadcafe.com/articles/20021016.asp

Da tale articolo, ecco alcune informazioni sul StateServer:

• in una Web farm, assicurarsi di avere la stessa MachineKey in tutti i tuoi server web. Vedi KB 313091 su come farlo.
• Inoltre, assicurarsi che gli oggetti siano serializzabili. Vedi KB 312112 per i dettagli.
• Per mantenere lo stato della sessione tra diversi server Web nella Web farm, il percorso dell'applicazione del sito Web (ad esempio \ LM \ W3SVC \ 2) nella metabase IIS deve essere identico in tutti i server Web nella Web farm . Vedi KB 325056 per dettagli

Answer 2

Stiamo usando StateServer per una web farm molto piccola con solo due nodi per poche centinaia di utenti.

Non sono responsabile per il suo funzionamento ma ricordo solo due problemi in due anni in cui è stato necessario riavviare il servizio perché si è bloccato.

Answer 3

Ho usato solo sql e in-proc. Ma questi 3 che si applicano quando si utilizza SQL Server si applicano anche:

• Evitare di memorizzare troppe informazioni nella sessione, poiché riguarda sia la serializzazione che i dati trasmessi sulla rete.
• Assicurati di non avere nulla che dipende da Session_onEnd. Questo non è disponibile per le sessioni fuori processo.
• Disattiva la sessione nelle pagine che non la utilizzano. Questo non fa la differenza per la sessione in-process, ma per il fuori processo ti farà risparmiare parecchio.

Answer 4

Assicurarsi che gli ID di accesso al server siano sincronizzati attraverso la Web farm, altrimenti la memorizzazione nella cache nei browser client sarà disturbata.

Hai esaminato il tuo codice in dettaglio per assicurarti che tutto possa essere serializzato fuori dal processo e attraverso una LAN in modo efficiente?

Stai risolvendo il problema principale delle prestazioni nel tuo sistema? Chiedo perché il database è la fonte tipica di contesa.

La mia motivazione principale per allontanarmi da sessioni appiccicose era la flessibilità operativa, ovvero un ciclo di un server problematico o l'aggiornamento di un software. Quindi, dopo aver implementato un servizio di sessione centrale, assicuratevi di trarre il massimo vantaggio da un punto di vista operativo.

Answer 5

Nella mia esperienza abbiamo scoperto che il server di stato nativo o anche l'utilizzo di SQL Server per le sessioni è uno scenario molto spaventoso in quanto entrambi hanno problemi (principalmente prestazioni). A proposito, stiamo anche usando sessioni appiccicose.

Penso che tu possa esplorare altri prodotti per ottenere il meglio. Un'opzione gratuita sarebbe Velocity ma non è ancora stata rilasciata. E un altro prodotto completo ma comprovato sarà (molto costoso in realtà) NCache. Questo ti aiuterà anche nelle tue serilizzazioni con meno costi, Se usi le loro API, i risultati saranno ancora migliori.

Dai uno sguardo e vedi quale è l'aspetto migliore per te.

Informazioni su SQL Server, il server morirà molto presto se si ha un numero sufficiente di hit in arrivo (credo che tu abbia già alcuni hit che ti hanno portato a fare Web Farm o lo fai solo per motivi di ridondanza)

Bottom line: stiamo valutando Velocity perché NCAchce è molto costoso. Tuttavia i vantaggi sono enormi.

Answer 6

Vorrei un altro punto in più per la risposta accettata:

• assicurarsi che la versione di DLL quadro è lo stesso.

Nel mio caso le versioni di DLL di System.Web erano diverse in quanto alcuni aggiornamenti di Windows venivano saltati su uno dei server della farm.