相关疑难解决方法(0)

我刚刚发现,ASP.Net Web应用程序中的每个请求在请求开始时都会获得一个Session锁,然后在请求结束时释放它!

如果这对你造成影响,就像我一开始对你而言,这基本上意味着以下几点:

• 任何时候ASP.Net网页需要很长时间才能加载(可能是由于数据库调用速度慢等),并且用户决定他们想要导航到另一个页面,因为他们厌倦了等待,他们不能!ASP.Net会话锁强制新页面请求等待,直到原始请求完成其缓慢的负载.Arrrgh.

• 任何时候UpdatePanel加载缓慢,并且用户决定在UpdatePanel完成更新之前导航到另一个页面......他们不能!ASP.net会话锁强制新页面请求等待原始请求完成其缓慢的负载.双Arrrgh!

那有什么选择呢？到目前为止,我想出了:

• 实现ASP.Net支持的自定义SessionStateDataStore.我没有找到太多的副本,它似乎有点高风险,容易搞砸.
• 跟踪正在进行的所有请求,如果来自同一用户的请求,则取消原始请求.看起来有点极端,但它会起作用(我认为).
• 不要使用Session!当我需要用户的某种状态时,我可以使用Cache代替,以及经过身份验证的用户名上的关键项,或者其他类似的东西.再次看起来有点极端.

我真的不敢相信ASP.Net微软团队会在版本4.0的框架中留下如此巨大的性能瓶颈!我错过了一些明显的东西吗 为会话使用ThreadSafe集合有多难？

我们在网站上遇到与高CPU使用率相关的性能问题.使用分析器时,我们已经确定了一个需要约35秒才能返回的特定方法.

这是使用名为SagePay的支付网关时的回拨方法.

我已经复制了下面这个调用的两个方法:

 public void SagePayNotificationReturn()
    {
        string vendorTxCode = Request.Form["vendortxcode"];

        var sagePayTransaction = this.sagePayTransactionManager.GetTransactionByVendorTxCode(vendorTxCode);
        if (sagePayTransaction == null)
        {
            // Cannot find the order, so log an error and return error response
            int errorId = this.exceptionManager.LogException(System.Web.HttpContext.Current.Request, new Exception(string.Format("Could not find SagePay transaction for order {0}.", vendorTxCode)));
            ReturnResponse(System.Web.HttpContext.Current, StatusEnum.ERROR, string.Format("{0}home/error/{1}", GlobalSettings.SiteURL, errorId), string.Format("Received notification for {0} but the transaction was not found.", vendorTxCode));
        }
        else
        {
            // Store the response and respond immediately to SagePay
            sagePayTransaction.NotificationValues = sagePayTransactionManager.FormValuesToQueryString(Request.Form);
            this.sagePayTransactionManager.Save(sagePayTransaction);
            ReturnResponse(System.Web.HttpContext.Current, …

我有一个MVC项目,我正在考虑加快速度.我正在摸索的一件事是我无法控制的BeginProcesRequest().使用New Relic我发现这种方法平均占用了交易完成所需时间的90%.

我的控制器中的代码非常简单.它查找用户的操作会话,并在找到时重定向到其仪表板.实际页面上没有任何数据库调用.唯一写的是:

if (Session["UserID"] != null)
// Perform actions

正如您在屏幕截图中看到的那样,BeginProcessRequest()方法大约需要4秒

这不是我网站的独特之处吗？我正在为服务器使用一个小的EC2实例,虽然在站点上运行其他应用程序,但CPU和内存在整个请求期间几乎保持为0.

EDIT - 审查了以下帖子:

BeginProcessRequest()会发生什么？

但是,当我的应用程序在最耗时的请求发生时处于空闲状态时,我无法看到它与竞争线程的关系.

我们有两个Web应用程序(Azure Web角色),它们在System.Web.HttpApplication.BeginRequest期间偶尔会出现长时间延迟(40到60秒).我们知道这一点,因为我们正在使用NewRelic来监控我们的网络应用.通常的罪魁祸首是由于ASP.NET的会话状态锁定机制导致的线程敏捷性问题,但是我们不使用ASP.NET会话状态,并且在其中一个站点上我们根本不使用会话.

一个应用程序比另一个应用程序复杂得多,并且遭受更多延迟,但我会在这个问题中使用简单的应用程序来希望缩小根本原因.

简单的Web应用程序是一系列基于ServiceStack的Web服务.它不使用会话.它仅充当基于WCF的服务层的中介.它主要是将请求传递给WCF服务,然后将响应映射到视图以传输回代理.服务器甚至不会在它们运行的​​负载上出汗(最大2.5%的CPU).

那么,可能的原因是什么？

1. 我最好的猜测是它是一个线程敏捷问题,因为它似乎在等待某些事情,这会暗示某个地方存在锁定.但是,如果不是会议状态,还等什么呢？NewRelic或ServiceStack导致锁定？
2. NewRelic的报告是错误的,没有问题.好吧,NewRelic在我们以前使用ASP.NET会话状态时正确地报告了问题并且正在获得更多这些延迟.