加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程开发 > asp.Net > 正文

IHttpAsyncHandler和ASP.NET“请求执行”计数器的问题

发布时间:2020-12-16 00:03:28 所属栏目:asp.Net 来源:网络整理
导读:解决:我找到了解决方案.不知道为什么会发生这种情况但是将“应用程序池类型”从“集成”切换为“经典”可以解决问题.现在’Requests Executing’继续上升,实际的应用程序池进程线程仍然很低(~31个线程),并且应用程序响应非常快(应该如此). 我正在使用.Net 2
解决:我找到了解决方案.不知道为什么会发生这种情况但是将“应用程序池类型”从“集成”切换为“经典”可以解决问题.现在’Requests Executing’继续上升,实际的应用程序池进程线程仍然很低(~31个线程),并且应用程序响应非常快(应该如此).
我正在使用.Net 2.0所以也许有一个问题 – 尝试google但没有运气.

见Joe Enzminger’s reply for an explanation

再次感谢大家.
PS.该代码用于在线播放池(台球) – windows(免费)版本here为任何好奇和勇敢的人尝试:)

你好,

我已经实现了一个IHttpAsyncHandler,客户端应用程序“轮询”等待服务器通知.通知由服务器上的其他“活动”生成,而异步处理程序根本不起作用.

执行步骤是:

IHttpAsyncHandler.BeginProcessRequest

    Create AsyncResult instance and add it to a "registered clients" collection

    return the AsyncResult

…其他服务器活动将生成要发送给注册客户的通知……

AsyncResult.CompleteCall called as a result of the generated notification(s).

IHttpAsyncHandler.EndProcessRequest is called

    The notification(s) attached to the AsyncResult are written to the response stream.

问题:

我已经在具有Windows Server 2008 SP2和1个cpu核心的VM上的IIS7上测试了这个.在12个客户端注册通知(使用Async.ashx上的HTTP GET)后,性能降低到后续客户端无法连接的程度.

当我检查ASP.NET性能计数器时,“Requests Executing”计数器随每个客户端注册而上升并保持在12(这似乎是它的最大值 – 可能是每个CPU的线程池大小).

我觉得这很令人困惑.我虽然异步处理程序的重点是为其他连接释放线程.看来情况并非如此,所以我一定做错了!

为什么ASP.NET在等待我的AsyncResult完成时消耗一个线程?这是配置问题吗?我是否需要做一些特定的事情来表明这是一个异步处理程序?

谢谢,
尼科斯.

编辑:添加以下代码:

public class AsyncResult : IAsyncResult
{
    private AsyncCallback _cb;
    private object _state;
    private ManualResetEvent _event;
    private bool _completed;
    private bool _completedsynchronously;
    private HttpContext _context;
    private byte[] _data;
    private int _datalength;
    private object _lock = new object();

    public AsyncWaitResult(AsyncCallback cb,object state,HttpContext context)
    {
        _context = context;
        _cb = cb;
        _state = state;
    }

    public void Close()
    {
        if (_event != null)
        {
            _event.Close();
            _event = null;
        }
    }

    public HttpContext Context { get { return _context; } }
    public Object AsyncState { get { return _state; } }
    public bool CompletedSynchronously { get { return _completedsynchronously; } }
    public bool IsCompleted { get { return _completed; } }
    public byte[] Data { get { return _data; } }
    public int DataLength { get { return _datalength; } }

    public WaitHandle AsyncWaitHandle
    {
        get
        {
            lock (_lock)
            {
                if (_event == null)
                    _event = new ManualResetEvent(_completed);
                return _event;
            }
        }
    }

    public void CompleteCall(byte[] data,int length,bool completedsynchronously)
    {
        _data = data;
        _datalength = length;
        _completedsynchronously = completedsynchronously;

        lock (_lock)
        {
            _completed = true;
            if (_event != null)
                _event.Set();
        }

        if (_cb != null)
            _cb(this);
    }
}


public class Outbound : IHttpAsyncHandler
{
    public IAsyncResult BeginProcessRequest(HttpContext context,AsyncCallback cb,object state)
    {
            AsyncResult asyncresult = new AsyncResult(cb,state,context);

            RegisteredClients.Instance.Add(asyncresult);

            return asyncresult;
    }

    public void EndProcessRequest(IAsyncResult ar)
    {
        AsyncResult result = (AsyncResult)ar;
        if (result != null)
        {
            result.Context.Response.Cache.SetCacheability(HttpCacheability.NoCache);
            result.Context.Response.ContentType = "application/octet-stream";
            result.Context.Response.AddHeader("Connection","keep-alive");

            if (result.Data != null)
                result.Context.Response.OutputStream.Write(result.Data,result.DataLength);

            result.Close();
        }
    }

    public void ProcessRequest(HttpContext context){}

    public bool IsReusable { get { return true; } }
}

解决方法

这是一篇博客文章,解释了您所看到的内容:

http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx

和同伴帖子

http://blogs.msdn.com/b/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx

在集成管道模式下,使用默认配置,IIS7为每个CPU设置了12个并发REQUESTS(非线程)的限制.您可以通过修改配置来更改此设置.

我不能放手.我很确定这就是你所看到的.深入探讨这篇文章,我真的不喜欢他们所做的改变,因为它显然会导致这样的问题,但我该判断谁呢!

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读