SQLServer vs StateServer pour les performances d'état de session ASP.NET
J'étudie pour une certification MS et l'un des tests pratiques que je fais a une question où le point de discorde est la performance entre le stockage de la session dans SQL Server par opposition à StateServer.
Étant donné que l'application s'exécute dans une batterie de serveurs Web, quelle solution pour l'état de session donne les meilleures performances (SQL Server ou StateServer) et, surtout, pourquoi?
State Server est plus rapide car il stocke les données de session dans un dictionnaire en mémoire. SQL Server est plus lent car il est stocké dans une base de données qui conserve les données sur le disque.
Le serveur SQL est également plus lent car tout est stocké dans une table, ce qui conduit à des conflits car de plus en plus de clients accèdent/mettent à jour les données de session.
Le serveur SQL est plus fiable car il est conservé sur le disque et peut être configuré en tant que cluster avec capacité de basculement.
Voir le préambule dans cet article pour une explication approfondie.
Une petite note, mais importante: InProc n'est pas utilisable dans une batterie de serveurs, comme son nom l'indique, il s'exécute dans le processus w3wp actuel et ne peut pas être partagé sur une batterie de serveurs. StateServer est un service Windows, donc la vitesse d'utilisation de StateServer dépend de la vitesse à laquelle la machine sur laquelle le service Stateserver fonctionne, c'est uniquement de la mémoire. SQL doit bien sûr écrire les données et les récupérer, ce qui est probablement plus lent que la mémoire uniquement.
De ici :
- En cours. Dans le processus fonctionnera mieux car la mémoire d'état de session est conservée dans le processus ASP.NET. Pour les applications Web hébergées sur un seul serveur, les applications dans lesquelles l'utilisateur est garanti d'être redirigées vers le serveur approprié, ou lorsque les données d'état de session ne sont pas critiques (dans le sens où elles peuvent être reconstruites ou re-remplies) , c'est le mode à choisir.
- Hors processus. Ce mode est mieux utilisé lorsque les performances sont importantes, mais vous ne pouvez pas garantir à quel serveur un utilisateur demandera une application. Avec le mode hors processus, vous obtenez les performances de lecture à partir de la mémoire et la fiabilité d'un processus distinct qui gère l'état de tous les serveurs.
- Serveur SQL. Ce mode est mieux utilisé lorsque la fiabilité des données est fondamentale pour la stabilité de l'application, car la base de données peut être mise en cluster pour les scénarios de défaillance. Les performances ne sont pas aussi rapides qu'en dehors du processus, mais le compromis est le niveau de fiabilité plus élevé.
À partir de ce lien: http://www.eggheadcafe.com/articles/20021016.asp
Performance
InProc - Plus rapide, mais plus il y a de données de session, plus la mémoire est consommée sur le serveur Web et cela peut affecter les performances.
StateServer - Lors du stockage de données de types basiques (par exemple chaîne, entier, etc.), dans un environnement de test, il est 15% plus lent qu'InProc. Cependant, le coût de la sérialisation/désérialisation peut affecter les performances si vous stockez de nombreux objets. Vous devez effectuer des tests de performances pour votre propre scénario.
SQLServer - Lors du stockage de données de types basiques (par exemple chaîne, entier, etc.), dans un environnement de test, il est 25% plus lent qu'InProc. Même avertissement sur la sérialisation que dans StateServer.
Il semblerait donc que StateServer est un peu plus rapide que SQL Server pour stocker l'état de session.
En ce qui concerne le pourquoi, je suggère que SQL Server est plus polyvalent et sera probablement utilisé pour d'autres choses également. Non seulement cela, mais le mécanisme de stockage est sur le disque, alors que le StateServer s'exécute dans un processus distinct, il stocke simplement les données dans l'espace mémoire de l'autre processus plutôt que d'avoir à les écrire sur le disque (si la mémoire virtuelle le permet)
SQL Server (In Memory) est la réponse - disponible dans SQL 2014