asp.net, Stateserver, NLB, session perdue

Question

1er message sur stackoverflow, espérons avoir d'excellents retours:)

J'essaie actuellement d'équilibrer notre site Web. Nous avons configuré un NLB à 2 grappes sur Windows Server 2003 avec IIS 6.

Lors du test de la configuration, j’ai constaté que parfois, notre session était perdue. Un jour et demi plus tard, voici le résultat:

1. Oui, notre machine.config a la même clé de chiffrement / déchiffrement.
2. Oui, les identifiants dans iis metabase.xml sont les mêmes pour les deux ordinateurs. En fait, l’ensemble du fichier est identique, à l’exception de "AdminACL".
3. Les deux applications Web sont définies avec " StateServer " et les deux pointant sur la même machine.

À partir de là, la recherche sur Google donne moins d'informations et de solutions possibles.

D'après ce que je sais, il n'y a pas de schéma particulier à l'origine de ce problème. Cela se produit de temps en temps.

Tout en essayant de trouver le problème, j'ai constaté qu'une requête envoyait le cookie d'identification de session asp au serveur, mais le serveur ne l'avait pas mappé à la session de l'utilisateur.

Ainsi, le numéro de demande x a été envoyé par le client, avec le cookie, la session a été mappée et tout s’est déroulé sans encombre. Le numéro de demande x + 1 a été envoyé par le client avec le cookie, mais la session n'a pas été trouvée.

Les deux demandes ont été effectuées sur le même ordinateur dans le NLB.

Voici un extrait du fichier asp trace.axd:

1ère demande:

Détails de la demande Identifiant de session: j2ffvy45updpc52uhw1mbg55 Type de demande: GET Heure de la demande: 11/26/2008 14:58:06 Code statut: 200 Codage de la demande: codage de la réponse Unicode (UTF-8): Unicode (UTF-8)

Demander la collecte de cookies

Nom Valeur Taille

ASP.NET_SessionId j2ffvy45updpc52uhw1mbg55 42 AIDE 22 9

Collection de cookies de réponse

Nom Valeur Taille

Collection d'en-têtes

Nom Valeur

Cookie ASP.NET_SessionId = j2ffvy45updpc52uhw1mbg55; AID = 22

2ème demande:

Détails de la demande Identifiant de session: Type de requête: POST Heure de la demande: 26/11/2008 14:58:08 Code Statut:
Demande de codage: codage de réponse Unicode (UTF-8):

Demander la collecte de cookies

Nom Valeur Taille

Collection de cookies de réponse

Nom Valeur Taille

Collection d'en-têtes Nom Valeur Cookie ASP.NET_SessionId = j2ffvy45updpc52uhw1mbg55; AID = 22

Comme vous pouvez le constater dans la deuxième demande, le cookie est envoyé par le client, mais asp ne semble jamais ajouter de cookies dans la section "Demande de collecte de cookies". Je pense que c'est pourquoi il ne trouve pas la session.

Alors, pourquoi le cookie n'est pas mappé à la session? Est-ce le problème? Le problème est-il ailleurs?

N'hésitez pas à demander des éclaircissements.

Merci à tous pour vos commentaires.

JF

Answer 1

J'ai enfin trouvé la réponse à mon problème. Son origine se trouve dans le code de l'application (comme 99% des "bogues" des outils tiers d'un programmeur). J'ai décidé de le poster quand même, au cas où quelqu'un se trouverait dans un scénario similaire.

Ce code faisait partie de la classe WebServiceRequester. La classe de demandeur de service Web a été instanciée lors de la création de la session et enregistrée dans la session. Lors de la création, nous initialisons le membre 'm_webServiceURL', et ce membre est enregistré dans session après. À quelle valeur l'initialisation de ce membre dépendait-elle d'un paramètre défini sur la machine locale.

La partie importante est la suivante: La classe WebServiceRequester contient un objet WebService. Les objets WebService ne peuvent pas être enregistrés en session, ils ne sont pas sérialisables en asp. La propriété avait l'attribut [NonSerialized]. Ainsi, chaque fois que nous accédions à la propriété 'WebService' de l'objet pour la première fois au cours d'un cycle de vie d'une page, nous devions en créer une nouvelle et lui attribuer l'URL 'm_webServiceURL' qui était enregistrée en session. Vous voyez donc un nouvel objet Webservice, éventuellement sur une machine différente, ce qui signifie un paramètre différent sur chaque machine.

alors voici ce qui s'est passé: la case 29 était configurée pour accéder au service Web chez localhost

La case 30 a été configurée pour accéder au service Web en tant que 192.168.253.29.

Techniquement, ils sont tous deux installés sur la même machine. Mais voici un scénario:

connexion à la case 29. m_webServiceURL est défini sur localhost en session.

[une requête sur la case 29 ici]

L’équilibrage NLB nous ramène à la case 30. case 30 charge sa session, créez un nouvel objet de service Web avec localhost comme adresse de service Web. La case 30 a envoyé la demande au mauvais service Web, ce qui a entraîné une exception Session expirée.

Un des problèmes rencontrés lors du débogage était que les communications locales n’avaient pas été enregistrées avec le moniteur réseau.

Ce qui m'a amené à suivre, c'est que nous n'avons jamais eu d'exception enregistrée dans la trace du journal de la boîte 29, comme il aurait dû l'être.

Merci pour vos suggestions, tout le monde a été très apprécié.

Passez une bonne journée. JF

Answer 2

Ce n'est pas strictement une réponse à votre question, mais l'avez-vous essayé en utilisant un magasin de session basé sur un serveur SQL? (Recherchez le script permanent sur MSDN plutôt que le script temporaire fourni avec asp.net)

J'ai entendu "mauvaises choses". sur le service de session exécutable, et par conséquent ne l’ont pas utilisé. Vous n’avez jamais rencontré de problème d’agriculture Web avec la solution basée sur un serveur SQL.

Désolé, ce n'est pas strictement une réponse à votre problème, mais il convient soit (a) de le résoudre, soit (b) de le réduire de manière significative.

Answer 3

Eh bien, si vous utilisez Visual Studio, vous pouvez au moins le tester avec le MSDE (version simplifiée de SQL Server fournie avec Visual Studio) ...

Cela pourrait aider à éliminer les problèmes de serveur d'état ...

Answer 4

L’utilisation de la base de données a ses propres problèmes. Je pense que vous devriez pouvoir utiliser votre approche préférée.

Peut-être cet article de dépannage de session aiderait?

Ou & Résolution des problèmes liés aux sessions dans ASP.NET "

Ou & Dépannage de l'état de session ASP.NET expiré et de vos options "

Answer 5

Je vais être boiteux et réitérer la proposition de MS SQL Server. Installez SQL Server Express qui est entièrement gratuit, y compris pour un usage commercial. Il ne présente que ces 3 inconvénients qui ne devraient pas vous poser de problèmes à cette étape:

• Base de données de taille maximale 4 Go
• 1 cœur utilisé maximum
• 1 Go maximum de RAM utilisé

Answer 6

Quelques points à prendre en compte:

• Quelle est la charge sur votre site Web? State Server a tendance à se bloquer lorsqu'il fait face à un grand nombre de hits simultanés. Nous ne l'utilisons que dans des scénarios où nous avons un très petit nombre d'utilisateurs (dans les 10, principalement des systèmes dorsaux). Chaque fois que nous essayions de l'utiliser en production pour des sites desservant quotidiennement des milliers d'utilisateurs, il se bloquait, entraînant une perte de données de session.
• Dans l'un des environnements de production que nous gérons, nous utilisons MSSQL 2005 Express pour gérer les sessions. Le site compte plus de 10 000 utilisateurs par jour et plus de 200 000 pages par jour. Cette approche est recommandée dans les cas où la session est indispensable et étroitement couplée à votre application.

Si vous êtes sur le point d’utiliser MSSQL Express en tant que base de données d’état, rappelez-vous qu’il n’est pas fourni avec SQL Server Agent, ce qui signifie qu’aucun planificateur de tâches ne s’exécute en arrière-plan et ne nettoie pas les sessions expirées. Je vous conseillerais de trouver un planificateur et d'exécuter périodiquement la procédure stockée des sessions vides après expiration.

Bonne chance

Answer 7

Au lieu de jouer avec SQL, envoyez vos tests directement dans l’un de vos nœuds IIS pour voir si vous rencontrez toujours le même problème. Je suis sûr que le problème ne se posera pas si vous ne faites qu'un petit nombre de tests sur StateServer.

Answer 8

Essayez de définir le nom de domaine de asp.net_sessionid via le code sur ".votdomain.com". Par défaut, le nom de domaine du cookie ASP.net_SessionID est défini sur le chemin d'accès complet de l'application. C'est peut-être l'une des raisons pour lesquelles le cookie ne voyage pas.

E.g. Request.Cookies ["ASP.NET_SessionId"]. Domain = ".votdomain.com". Rappelez-vous le premier ". & Quot; est important dans le nom de domaine.

Vous pouvez le faire dans le HttpModule de l'événement AcquireRequestState.