Imagerie Il y a 2 pages sur le site Web: rapide et lent. Les demandes de la page ralentissent sont exécutées pendant 1 minute, demandez de 5 secondes rapides.
tout entière ma carrière de développement, je pensais que si la première demande de démarrage est lente: il fera un appel (synchrone) à db ... attendre la réponse ... Si lors de cette demande de temps à la page rapide sera effectuée, cette demande sera effectuée. être traitée pendant que le système attend la réponse de la DB.
Mais aujourd'hui j'ai trouvé: http://msdn.microsoft.com/en-us/library /ystem.web.httpApplication.aspx
Une instance de la classe HTTPAppLication est utilisée pour traiter de nombreuses demandes dans sa vie. Cependant, il ne peut traiter qu'une seule demande à la fois. Ainsi, les variables des membres peuvent être utilisées pour stocker des données par demande.
Cela signifie-t-il que mes pensées originales sont fausses?
Pourriez-vous s'il vous plaît clarifier ce qu'ils veulent dire? Je suis à peu près sûr que ce sont comme je m'attends ...
3 Réponses :
Vos pensées originales ont raison, de même que la documentation. Le processus de travailleur de l'IIS peut accéder à de nombreux threads, chacun avec son propre instance de la classe httpApplication .
Apparemment, il peut aussi dépeter Stackoverflow. com / questions / 2675910 / ...
Voulez-vous dire qu'il est possible d'avoir plusieurs instances de httpApplication à tout moment. Cela n'a pas beaucoup de sens pour moi ... suis-je correctement compris que seul le 1er thread créé devrait générer un événement "Application_Start"?
BTW, merci de votre aide. :)
La classe httpApplication est juste une classe , je pense que vous y réfléchissez comme quelque chose que ce n'est pas. Je vous recommande de regarder plus profondément dans l'architecture de pipeline ASP.NET. Voyez ici: msdn.microsoft.com/en-us/magazine/cc188942.aspx
Oui, il est possible d'avoir plusieurs httpaplications à un moment donné. Chacun occupe un fil exclusivement pendant la durée d'une demande. Ainsi, une application httpApplication par demande, mais elle peut être réutilisée sur des demandes. Disons qu'une demande est en cours et que IIS reçoit une nouvelle demande. Il créera une nouvelle instance httpApplication dans l'une des AppDomains de WebApp et servira la demande à l'aide de la nouvelle httpApplication. Application_Start dans Global.Asax est une chose amusante. Il ne fonctionne réellement qu'une fois par AppDomain, pas httpApplication. L'une autre main, des choses comme httpmodules exécutées une fois par httpApplication.
Je peux donc mettre des ressources hautes (lentes) apatrides dont la concurrence que je ne veux pas traiter dans httpaplylication._ctor () et httpApplication.dispose () .
ASP .NET accueillera plusieurs appdomains pour votre application Web sous un processus de travail unique (W3WP.exe). Il peut même partager AppDomains pour différentes applications Web dans le même processus de travail (s'ils sont attribués au même pool d'applications).
Chaque appdomain que ASP .NET crée peut héberger plusieurs instances HTTPAppLication qui servent des demandes et de la promenade via le cycle de vie ASP .NET. Chaque httpApplication peut (comme vous l'avez dit) répond à une demande à la fois.
Devinez, vous voulez dire "ASP .NET hébergera plusieurs appdomains pour vos applications Web". De mon point de vue, il n'a aucun sens d'avoir peu de domaines d'application pour une application Web. Ai-je raison?
BTW, merci de votre aide. :)
À partir d'un point de vue multiple de l'application Web, cela fait des tonnes de sens. Vous ne voulez certainement pas que deux applications Web différentes fonctionnent dans la même AppDomain et partagent des ressources à partir d'un point de vue de la sécurité. En général, si je comprends bien, le but d'exécuter des appdomains séparés dans un seul processus travailleur est destiné à la stabilité, une seule défaillance d'AppDomain n'apporte pas l'application Web totale.
«Objectif d'exécution d'AppDomains distincts au sein d'un seul processus travailleur» est clair pour moi et je suis absolument d'accord avec cela. Mais si je répandre mon application Web via quelques domaines d'application, comment puis-je utiliser "Singletons" dans ce cas? J'ai besoin de contourner beaucoup de choses (fournisseur de cache unique, etc.) ... Mais ce que cela me donne?
Oui, vos singletons et votre mise en cache seront spécifiques à l'appdomain, il s'agit d'utiliser, à moins que vous n'utilisiez une session partagée ou un serveur de cache (hors process). Vous rencontrez des mêmes problèmes si vous disposez de plusieurs serveurs frontaux de charge équilibrés.
En d'autres termes, des valeurs statiques dans une application ASP .NET sont dangereuses et doivent être évitées pour la plupart sans examen minutieux (cela peut être une surestimation, mais simplement faire un point).
Jeff, merci encore. D'accord, il y a des problèmes supplémentaires ... mais toujours, je ne vois pas de valeur pour avoir une application Web diffusée entre peu de domaines ... pourriez-vous être si gentille de clarifier?
Je viens de trouver ceci: msdn.microsoft.com/en-us/library/7w2Sway1. ASPX . Voir maxappdomains.
Les demandes doivent être traitées dans l'ordre séquentiel du côté serveur si la requête utilise la même session État de la même session avec un accès en lecture / écriture, en raison du verrouillage de la session ASP.NET.
Vous pouvez trouver plus d'informations ici: http://msdn.microsoft.com/en-us/library/ie /ms178581.aspx
Demandes simultanées et état de session
L'accès à l'état de session ASP.NET est exclusif par session, ce qui signifie que si deux utilisateurs différents font des demandes simultanées, l'accès à chaque session distincte est accordé simultanément. Toutefois, si deux demandes simultanées sont effectuées pour la même session (en utilisant la même valeur de la sessionId), la première demande reçoit un accès exclusif aux informations de session. La deuxième requête n'existe qu'après la fin de la première demande. (La deuxième session peut également avoir accès si le verrouillage exclusif sur les informations est libéré car la première requête dépasse le délai de verrouillage.) Si la valeur EnableSessionState dans la directive @ page est définie sur Lecture, une demande de lecture seule Les informations de session n'entraînent pas une serrure exclusive sur les données de session. Toutefois, les demandes de données en lecture seule pour les données de session ont toujours besoin d'attendre un verrouillage défini par une demande de lecture de données de lecture pour effacer.
Toute idée de ce qui se passe avec ASP.MVC actions marquées avec l'attribut [allowanonymous] ? Est-ce qu'ils sont également sérialisés, lorsqu'ils sont générés par la même session, malgré le fait que vous ne touchez pas la session?
Toute personne qui court sur ce problème pourrait vérifier cette solution pour conserver la demande de traitement parallèle et améliorer les performances: Stackoverflow.com/a/50983771/2173353