此函数调用可能需要300毫秒到100秒(严重的是100秒).我试图搜索msdn文档,但http://msdn.microsoft.com/en-us/library/system.web.mvc.mvchandler.aspx上没有任何内容
显然,这里有些东西在骗我.
我有一些理论说明为什么这么长时间：
>类型推断？我正在使用结构图.
>服务器资源问题？
> .net版本不兼容某种？
> asp.net mvc某种不兼容性？
环境：
.net 4
asp.net mvc 3
专用的vm
解决方法
因此,我认为它可能是New Relic注入的东西,或者正如你所说的那样,是一种红鲱鱼,有些东西对我们说谎！我关闭了New Relic,并与他们的支持团队联系.
今天,在收到来自New Relic团队的一位反应灵敏且彬彬有礼的成员的几封电子邮件之后,他们又回到我身边并确认这是一个错误(各种各样).以下是他们的回复：
ProcessAsyncRequest is a custom name that we use for any metric being
recorded that is not / does not inherit from “System.Web.UI.Page.”
Given that MVC view engine uses “System.Web.Mvc.ViewPage” all of those
metrics will incorrectly fall under the New Relic moniker of
“ProcessAsyncRequest.”I will be working on a modification to the agent and the core
instrumentation that will hopefully aggregate these metrics
appropriately. I am sorry for the confusion and trouble this has
caused you.I’ll give you an update as I get close to a solution.
编辑：下面的New Relic的进一步回复 – 看起来他们有一个修复到位.
I just pushed a commit that will help us better classify the
transactions coming from the installed agent.As far as the performance issue we did discover an issue reported by
the awesome engineers at AppHarbor that was causing TypeLoadExceptions
which might be related to slow loading / compiling code being put into
the cache. We have found the cause and are in the final testing phases
of that fix and we are hoping to get the fix in the next release of
the agent.
来自New Relic的尼克非常出色地回应了这一点,他们的产品非常有用,所以我没有任何不好的感受,只是想我会在这里分享细节.
很高兴发现我的MVC应用程序中没有鬼魂！
现在,我对任何有这些问题的人的建议是关闭New Relic直到他们的下一个版本.
编辑2：New Relic的Nick今天通过电子邮件发送给我 – 他们最新的代理(版本2.0.9.15) – 现在已经可以使用,应该可以解决这个问题.
