longs retards dans AcquireRequestState
En utilisant l'outil de surveillance des performances "New Relic", je vois des retards occasionnels (mais trop nombreux) dans "AcquireRequestState". Je parle de retards de 10, 20 secondes, parfois de quelques minutes.
Je sais que nous n'avons pas écrit nos propres gestionnaires d'événements pour cet événement.
Où puis-je même commencer à chercher la cause de ces retards? Le peu d'informations que j'ai trouvées jusqu'à présent sur msdn n'a pas été utile.
Mon équipe a vu ce retard "AcquireRequestState" signalé par NewRelic plus tôt dans la journée, lorsqu'une de nos applications ASP.NET rencontrait des problèmes de performances sur une page particulière.
La cause première s'est avérée être une modification d'une procédure stockée que nous avions récemment déployée dans notre base de données SQL Server, ce qui entraînait par inadvertance l'exécution de cette procédure stockée très longtemps. La procédure stockée a été appelée dans le cadre de l'affichage de la page présentant le problème de performances.
Nous avons pu résoudre le problème en identifiant et en résolvant le problème de performances avec la procédure stockée. Le problème "AcquireRequestState" de NewRelic s'est avéré non pertinent; c'était un symptôme du problème plutôt qu'une cause.
C'était sur une application ASP.NET 4.5 exécutée sur Windows Server 2008.
tl; dr: Le délai "AcquireRequestState" signalé par NewRelic peut être un effet secondaire d'un autre problème qui provoque une ou plusieurs pages et/ou AJAX requêtes dans votre application ASP.NET pour prendre du temps à charger.
Essayez d'appliquer correctif cumulatif 2828841 sur le serveur.
Numéro 6
Symptômes
Lorsque vous envoyez de nombreuses demandes simultanées qui ont le même SessionId à une application Web ASP.NET 4.5, certaines demandes peuvent se bloquer de manière inattendue à l'étape RequestAcquireState.
Résolution
Après avoir appliqué le correctif, le correctif s'assure que l'événement EndRequest se déclenchera toujours.
Ce correctif s'applique à Windows 7 Service Pack 1 (SP1), Windows Server 2008 R2 SP1, Windows Server 2008 Service Pack 2 (SP2) et Windows Vista SP2.
Je soupçonne que votre changement de proc stocké pourrait mettre en évidence un problème légèrement différent en termes de verrouillage de session, nous avions à peu près le même signalement pour un scénario différent, je voudrais sérieusement vous encourager à tester le fournisseur de session asynchrone comme mentionné ici et en vous assurant que vous utilisez le paramètre des demandes simultanées par session:
https://stackoverflow.com/a/55331786/758105
En fin de compte, tout processus de longue durée (dans votre cas, le changement de proc stocké) bloque toute autre demande pour cette session. Étant donné que ce "bloc" se produit dans une autre partie du pipeline IIS, NewRelic l'enregistre simplement comme "AcquireRequestState"
PS: Je sais que cette réponse arrive assez tard mais j'ai finalement trouvé quelque chose qui a résolu un problème similaire pour nous et je pense que cela aidera beaucoup de gens à l'avenir.