Il n'y a absolument aucun doute à ce sujet. ASP.NET est arrivé à maturité et une bonne majorité des applications ASP.NET sont désormais à fort trafic et critiques. Cela signifie que vous ne pouvez pas vous permettre des temps d'arrêt imprévus de l'ensemble du site Web ou de certains des serveurs où de nombreux utilisateurs sont évincés. En effet, ces temps d'arrêt vous coûtent cher en perte de revenus et en mauvaise réputation difficile à réparer.
Le stockage de l'état de session ASP.NET, s'il n'est pas géré correctement, peut entraîner des temps d'arrêt imprévus. Microsoft propose quatre options de stockage pour l'état de session ASP.NET :
- InProc : Sessions conservées dans le processus de travail
- Serveur d'état : Session conservée dans un processus séparé
- Serveur SQL: Session conservée dans SQL Server
- Personnalisé: Session conservée dans un magasin personnalisé tiers
Les deux En cours et StateServer n'ont pas la capacité de répliquer l'état de session ASP.NET sur plusieurs serveurs et entraînent donc une perte de données si un serveur Web tombe en panne. En fait, si vous avez un seul Serveur d'état pour l'ensemble du site Web et qu'il tombe en panne, vous êtes totalement arrosé parce que tout votre site Web tombera en panne.
Serveur SQL est la troisième option de stockage pour l'état de session ASP.NET et fournit la redondance des serveurs et la réplication des données, car vous pouvez créer un cluster de base de données, en miroir ou en cluster à charge équilibrée.
Cependant, il est coûteux de configurer des clusters SQL Server et il existe des alternatives moins chères et plus viables. De plus, SQL Server (comme toutes les bases de données relationnelles) a été conçu pour stocker des données relationnelles structurées et non des BLOB ; tandis que l'état de session ASP.NET est stocké dans SQL Server sous forme d'objets BLOB. Ainsi, non seulement les sessions sont lentes à accéder, mais la base de données devient rapidement un goulot d'étranglement lorsque vous essayez de faire évoluer votre application.
Une bien meilleure alternative à tout cela consiste à utiliser l'option de stockage personnalisé de État de session ASP.NET et utiliser un cache distribué en mémoire (NCache) comme stockage d'état de session ASP.NET. NCache réplique les sessions sur plusieurs serveurs. Ainsi, si l'un des serveurs tombe en panne, il n'y a pas de perte de données de session. NCache est également beaucoup plus rapide d'accès que SQL Server car il est en mémoire. Pour terminer, NCache vous permet de mettre facilement à l'échelle le cluster de cache à mesure que la taille de votre batterie de serveurs Web augmente. Ajoutez simplement plus de serveurs de cache au cluster afin qu'il n'y ait jamais de goulot d'étranglement.
Et, mieux encore, aucune programmation n'est nécessaire pour utiliser NCache pour le stockage de l'état de session ASP.NET. Modifiez simplement votre web.config pour spécifier les éléments suivants :
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> |
Eh bien, si vous avez une application ASP.NET en cours d'exécution dans une ferme Web, jetez un œil à NCache et voyez comment cela améliorera votre stockage d'état de session ASP.NET. Voici quelques liens utiles pour NCache:
Vous pouvez commencer avec un minimum de deux serveurs dédiés dans un cluster de cache pour une disponibilité et une fiabilité élevées, puis il est recommandé de maintenir un rapport 4:1 entre vos serveurs Web/App et vos serveurs de cache pour obtenir des performances et une évolutivité optimales pour vos applications.