J'ai 2 pages ASP.
Je fais une demande à la première page de Firefox ( qui prend 30 secondes pour traiter sur le côté serveur em>), et pendant l'exécution de 30 SECONDS Je fais une autre demande de Firefox à la deuxième page (prend moins de 1 seconde de côté serveur), mais cela vient après 31 secondes. Parce que cela attend les premières demandes de terminer. P> Lorsque je demande à la première page de Firefox, puis demandez la deuxième page de c.-à-é que c'est juste instantané. P> ASP - IIS 6 En quelque sorte limiter chaque client à une demande ( demande de traitement longue em>) à la fois. J'ai besoin de contourner ce problème dans mon application client .NET. P> Ceci est testé dans 3 systèmes différents. Si vous souhaitez tester, vous pouvez essayer les scripts ASP à la fin. P> Ce comportement est identique dans une exécution longue SQL ou juste dans un fonctionnement ASP consommant du temps. p> Note: strong> p> Y a-t-il un moyen de contourner cela? p> Premier ASP: P>
<%
Response.Write "bla bla"
%>
3 Réponses :
Avez-vous essayé d'utiliser réponse.flush ? Qui pourrait provoquer l'envoi immédiat de la sortie tampon.
Cela ne fonctionne pas et j'ai besoin de résoudre cela en mode plus générique. Mon client .NET devrait travailler avec n'importe quel site ASP comme celui-ci.
est IIS (ou ce site Web en spécifique) pour avoir 1 max. connexions simultanées?
Non . . .
Est-ce spécifique à Firefox? Que diriez-vous de 2 demandes simultanées d'IE?
@shahkalpeh, si c'était ainsi l'utilisation d'une instance distincte, causerait toujours la demande de retard jusqu'à ce que celui de FF soit terminé.
Ceci est dû à la façon dont ASP gère des sessions. L'objet de session est un seul fileté et ne peut donc être accédé que par un fil de travail à la fois. Lorsqu'une deuxième demande arrive pour la même session que celle qui est déjà traitée par un thread existant que la demande est mise en file d'attente par ASP jusqu'à ce que l'objet de session soit disponible.
Cela se produit par défaut même si vous n'utilisez pas réellement l'objet de session dans les pages en question.
Par conséquent, lorsque vous faites une demande de FF et l'autre de cE, vous auriez deux sessions différentes, les deux demandes peuvent donc procéder simultanément. Vous auriez pu avoir le même effet en utilisant deux instances distinctes d'IE.
Si vous savez que vous n'avez jamais besoin de l'objet de session, vous pouvez entrer dans la configuration de l'application et l'éteindre (cela signifierait qu'aucune page ASP n'a jamais touché l'objet de session). Dans ce cas, ASP permettrait à plusieurs demandes de la même instance de navigateur à traiter en même temps (car il n'aurait aucun moyen de connaître les demandes provenant de la même instance de navigateur).
Toutefois, dans la plupart des cas, le code ASP a une utilisation pour l'objet de session (même son marquant simplement une session telle que connectée). Dans ce cas, vous êtes bloqué avec ce comportement que si vous séparez les deux pages ASP appelées dans des applications distinctes.
Vous pouvez également désactiver la session par page avec cette variable de page: <% @ EnableSessionState = Faux%> Informations sur la session créées sur d'autres pages, il existe toujours son juste le moteur ASP avec Skip the Pièce uniquement pour cette page.