Problèmes d'équilibrage de charge ASP.NET AJAX

Question

Ce serait une question pour toute personne ayant du code dans le dossier App_Code et utilisant un équilibreur de charge matériel.Il est vrai que l'équilibreur de charge matérielle pourrait être configuré sur des sessions persistantes pour résoudre le problème, mais dans un monde parfait, j'aimerais que la fonctionnalité soit désactivée.

Lorsqu'un fichier se trouve dans le dossier App_Code et que le site n'est pas précompilé, iis générera des noms de fichiers aléatoires pour ces fichiers.

server1 "/ajax/SomeControl, App_Code.tjazq3hb.ashx"
server2 "/ajax/SomeControl, App_Code.wzp3akyu.ashx"

Ainsi, lorsqu'un utilisateur publie la page et est transféré vers l'autre serveur, rien ne fonctionne.

Quelqu'un at-il une solution pour cela?Je pourrais passer à un site Web précompilé, mais nous perdrions la possibilité pour notre service QA de simplement promouvoir les fichiers modifiés.

Answer 1

Vous pouvez déplacer tout ce qui se trouve dans votre app_code vers une bibliothèque de classes externe si votre service QA peut promouvoir l'intégralité de cette bibliothèque.Je pense que vous êtes coincé avec des sessions collantes si vous ne trouvez pas un moyen pratique ou tolérable de passer à un site précompilé.

Answer 2

Le nœud <machinekey> sur les deux serveurs est-il défini sur la même valeur ?

Vous pouvez remplacer le fichier machine.config dans web.config pour définir cela.Cela doit correspondre, sinon vous pouvez vous retrouver dans des situations étranges comme celle-ci.

Answer 3

Votre équilibreur de charge prend-il en charge les sessions persistantes ?Lorsque cette option est activée, l'équilibreur acheminera la même adresse IP vers le même serveur encore et encore dans un certain laps de temps.De cette façon, toutes les requêtes (AJAX ou autre) d'un client atteindraient toujours le même serveur dans le cluster/la ferme.

Answer 4

Ok, commençons par le commencement...le truc MachineKey est vrai.Cela doit absolument être réglé de la même manière sur toutes les machines à charge équilibrée.Je ne me souviens pas de tout ce que cela affecte, mais fais-le quand même.

Deuxièmement, allez-y et précompilez le site.En fait, vous pouvez toujours publier de nouvelles versions, chaque fois qu'il existe un fichier .cs pour une page, cette page est recompilée.Ce qui devient délicat, ce sont les fichiers app_code qui sont compilés en une seule DLL.Cependant, si une modification y est apportée, vous pouvez télécharger la nouvelle DLL et encore une fois, tout devrait bien se passer.

Pour rendre les choses encore plus faciles, activez l'option « Nom fixe utilisé et assemblages d'une seule page ».Cela garantira que les éléments portent le même nom sur chaque compilation, vous pourrez donc simplement tester puis remplacer les fichiers .dll modifiés.

Cela dit, vous ne devriez pas avoir de problème tel quel.La requête est envoyée à IIS, qui se contente de servir la page et de la compiler selon les besoins.Si le code derrière est différent sur chaque machine, cela ne devrait vraiment pas avoir d'importance, le code est le même et cette machine fera référence à son propre code.La demande/publication réelle ne sait rien de tout cela et ne s'en soucie pas.Tout ce que j'ai dit ci-dessus devrait simplifier les choses, mais cela devrait quand même fonctionner...c'est donc probablement un problème de clé machine.

Answer 5

S'il s'agit d'un équilibreur de charge matériel, vous ne devriez pas avoir de problème, car tout ce que l'on sait ici est l'URL de la requête, dans laquelle le serveur compilerait la page demandée et la servirait.

le seul problème auquel je pense que vous pourriez avoir concerne la session et l'état d'affichage.

Answer 6

Il est vrai que l'équilibreur de charge matérielle pourrait être configuré pour des sessions persistantes pour résoudre le problème, mais dans un monde parfait, j'aimerais que la fonctionnalité soit désactivée.

Answer 7

Il semble que ce soit uniquement pour le cryptage ViewState.Cela n’affecte pas les noms de fichiers des assemblys compilés automatiquement.

Answer 8

Je pense que le modèle asp.net dépend beaucoup du cryptage et du stockage spécifique à la machine, donc je ne suis pas sûr qu'il fonctionne pour éviter une adresse IP collante pour la session.

Je ne connais pas ASP.NET AJAX (j'utilise plutôt l'approche MonoRail NJS), mais l'état de la session pourrait être un problème pour vous.

Vous devez vous assurer que les états de session sont sérialisables et n'utilisez pas de session InMemory.Vous devrez probablement exécuter ASP.NET Session State Server pour vous assurer que l'ensemble de la batterie frontale utilise le même stockage de session.Dans ce cas, la session doit être parfaitement sérialisable (c'est pourquoi aucun objet en session n'est préféré, vous devez toujours utiliser l'ID, et je parie que MS respecte cette limitation lorsqu'il développe une bibliothèque AJAX)