7
votes

Qu'est-ce que SYSTEM.WEB.MVC.MVCHANDLER.PROCESSASYNCREQUEST ()?

Je fais des traçages de Newrelic, et je vois presque toutes les demandes contiennent un appel à 'System.web.mvc.mvchandler.ProcessasynCrequest ()'.

Cet appel de fonction peut prendre n'importe où de 300 ms jusqu'à 100 ans (sérieusement, 100 ans). J'ai essayé de rechercher la documentation MSDN, mais il n'y a rien sur http: //msdn.microsoft.com/en-us/library/system.web.mvc.mvchandler.aspx

Clairement, quelque chose me ment ici.

J'ai quelques théories quant à la raison pour laquelle cela prend si longtemps:

  • Type Inference? J'utilise StructureMap.

  • Problèmes de ressource de serveur?

  • .NET Version Incompatibilité d'une sorte?

  • ASP.NET MVC Incomopaticabilité d'une sorte?

    Environnement:

    .NET 4

    ASP.NET MVC 3

    VM dédié


5 commentaires

Je vois que vous avez déjà demandé à ici ...


Oui, mais cette question a été abandonnée et je n'étais pas sûr que l'utilisateur l'examinera jamais. Déjà ma raison, ce qui est essentiellement le même problème a entraîné plus d'activité! :)


Je sais - mais affichez le lien ici permet aux réponses d'aller à cette question. Ensuite, votre question peut être fermée comme un duplicata. Yay! : D (sonne un peu morbide, maintenant que je le tape ...)


Définitivement morbide. Je m'en fiche de l'endroit où les réponses vont, tant que les réponses sont incitées. Installation des outils de traceur coûteux de fantaisie maintenant ...


Dans quel environnement voyez-vous ce comportement? Hôte partagé? Serveur dédié? Quelle version de mvc? Quelle version de .net?


3 Réponses :


1
votes

Avez-vous essayé d'installer un aperçu via Nuget et de regarder la demande?

Hanselman a blogué à ce sujet


1 commentaires

Passer avec DotTrace semble suggérer que cela peut être un problème de carte de structure. Ce que je peux croire causerait une performance frappé, mais cela ne change pas de fait que je n'utilise pas de contrôleurs asynchronisés.



2
votes

Avez-vous essayé de télécharger le code source MVC, le code MVC3 peut être trouvé ici:

http://aspnet.codeplex.com/relases/view/58781 < / p>

Avoir un a fait autour et déboguer votre site pour voir ce qui va faire - et gentiment rapporter! :)


1 commentaires

En regardant la source, il n'y a pas de méthode: ProcessaSynCrequest dans la classe Mvchandler. Semble un peu étrange. Est-ce quelque chose de spécifique à la nouvelle relique peut-être?



4
votes

Quand j'ai trouvé ce problème, je pensais la même chose que @garfbradaz et j'ai examiné la source MVC. C'était intéressant, car j'ai trouvé aucune référence à la méthode ProcessAsynCrequest .

Par conséquent, j'ai décidé que cela pourrait être quelque chose de nouveau relique injectant, ou comme vous le dites, un hareng rouge et quelque chose nous mentent! J'ai commuté de nouvelles reliques et j'ai contacté leur équipe de support.

Aujourd'hui, après quelques courriels d'un membre extrêmement réactif et courtois de la nouvelle équipe de relique, ils me sont retournés et ont confirmé que c'est un bogue (de toutes sortes). Voici leur réponse:

processasyncrest est un nom personnalisé que nous utilisons pour tout être métrique enregistré qui n'est pas / n'hérite pas de "System.Web.UI.Page". Étant donné que le moteur de vue MVC utilise "system.web.mvc.viewpage" tous ces Les métriques tomberont de manière incorrecte sous le nouveau relique moniker de "ProcessaSyncrest."

Je travaillerai sur une modification de l'agent et du noyau Instrumentation qui sauront espérer ces métriques de manière appropriée. Je suis désolé pour la confusion et les problèmes que cela a vous a causé.

Je vais vous donner une mise à jour lorsque je me rapproche d'une solution.

EDIT : Une réponse ultérieure de la nouvelle relique ci-dessous - on dirait qu'ils ont une solution en place.

Je viens de pousser un commit qui nous aidera mieux à classer le transactions provenant de l'agent installé.

En ce qui concerne la question de la performance, nous avons découvert un problème rapporté par Les ingénieurs géniaux d'APPHARBOR, qui causaient de la dactylographie qui pourrait être lié à la lenteur de chargement / compilation du code mis en place le cache. Nous avons trouvé la cause et sont dans les phases de test final de ce correctif et nous espérons obtenir le correctif dans la prochaine version de l'agent.

Nick de la nouvelle relique était excellent pour répondre à cela et leur produit a été vraiment utile, donc je n'ai pas de mauvais sentiments, je pensais juste que je partageais les détails ici.

Très heureux de savoir qu'il n'y a pas de fantômes dans mon application MVC quand même!

Pour l'instant, mon conseil à quiconque ayant ces problèmes est d'éteindre une nouvelle relique jusqu'à leur prochaine version.

edit 2 : Nick de la nouvelle relique m'a envoyé par courrier électronique aujourd'hui - leur dernier agent (version 2.0.9.15) - est maintenant disponible et devrait corriger ce problème.


3 commentaires

impressionnant! En fait, j'ai eu occupé à améliorer les performances ailleurs et je n'ai pas eu la chance de revenir à cela. Bon travail en suivant.


@dazbradbury j'ai la dernière version de l'agent 2.10.40.0 Et toujours la plupart de mes goulots d'étranglement sont System.Web.MVC.mvchandler.BeginProcessRequest ()


@Korayem Avez-vous envoyé une nouvelle équipe de relique? Pourrait être utile de lier à ce poste afin qu'ils puissent re-regarder de la question au cas où il est accéléré à nouveau. Je me suis éloigné de la nouvelle relique après cela, mais je tiens à leur donner une autre fois lorsqu'il est corrigé.