Non ci sono assolutamente dubbi al riguardo. ASP.NET è diventato obsoleto e una buona maggioranza delle applicazioni ASP.NET ora sono ad alto traffico e mission-critical. Ciò significa che non puoi permetterti tempi di inattività non programmati né dell'intero sito Web né di alcuni dei server in cui molti utenti vengono eliminati. Questo perché questi tempi di inattività ti costano caro in perdita di entrate e una cattiva reputazione che è difficile da riparare.
L'archiviazione dello stato della sessione ASP.NET, se non gestita correttamente, può causare tempi di inattività non pianificati. Microsoft offre quattro opzioni di archiviazione per lo stato della sessione ASP.NET:
- InProc: Sessioni mantenute all'interno del processo di lavoro
- StatoServer: Sessione mantenuta in un processo separato
- Server SQL: Sessione mantenuta in SQL Server
- Personalizzato: Sessione conservata in un negozio personalizzato di terze parti
Entrambi InProc e StateServer non hanno la capacità di replicare lo stato della sessione ASP.NET su più di un server e quindi causano la perdita di dati se un server Web si interrompe. In effetti, se ne hai uno State Server per l'intero sito Web e va giù, sei completamente incazzato perché l'intero sito Web non funziona.
Server SQL è la terza opzione di archiviazione per lo stato della sessione ASP.NET e fornisce la ridondanza del server e la replica dei dati perché è possibile creare un cluster di database, con mirroring o con bilanciamento del carico.
Tuttavia, è costoso configurare i cluster di SQL Server e sono disponibili alternative più economiche e praticabili. Inoltre, SQL Server (come tutti i database relazionali) è stato progettato per archiviare dati relazionali strutturati e non BLOB; mentre lo stato della sessione ASP.NET è archiviato in SQL Server come BLOB. Pertanto, non solo l'accesso alle sessioni è lento, ma il database diventa rapidamente un collo di bottiglia mentre si tenta di ridimensionare l'applicazione.
Un'alternativa notevolmente migliore a tutto questo consiste nell'utilizzare l'opzione di archiviazione personalizzata di Stato sessione ASP.NET e usa una cache distribuita in memoria (NCache) come archiviazione dello stato della sessione ASP.NET. NCache replica le sessioni su più server, quindi se un server si interrompe, non c'è perdita di dati di sessione. NCache è anche molto più veloce da accedere rispetto a SQL Server perché è in memoria. Infine, NCache ti consente di ridimensionare facilmente il cluster di cache all'aumentare delle dimensioni della tua web farm. Aggiungi semplicemente più server cache al cluster in modo che non ci sia mai un collo di bottiglia.
E, soprattutto, non è necessaria alcuna programmazione da utilizzare NCache per l'archiviazione dello stato della sessione ASP.NET. Modifica semplicemente il tuo web.config per specificare quanto segue:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<assemblies> <add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.4.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/> </assemblies> <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="NCacheTest" enableLogs="false" cacheName="myReplicatedCache"/> </providers> </sessionState> |
Bene, se hai un'applicazione ASP.NET in esecuzione in una web farm, dai un'occhiata a NCache e guarda come migliorerà l'archiviazione dello stato della sessione ASP.NET. Ecco alcuni link utili per NCache:
Puoi iniziare con un minimo di due server dedicati in un cluster di cache per garantire disponibilità e affidabilità elevate e quindi si consiglia di mantenere un rapporto 4:1 tra i server Web/app e i server di cache per ottenere prestazioni e scalabilità ottimali per le tue applicazioni .