Lab:体会ASP.NET异步处理请求的效果

关注我的朋友们一定记得,我不止一次强调过在ASP.NET应用程序中使用异步方式处理请求对于提高吞吐量的作用。不过似乎很多朋友们一直没有理解这样做的原因,亦或是对这样做的效果没有一个实际的“体会”,甚至在质疑这么做的功效。现在我将向大家进行一个演示,我们一起来看一下这么做的实际效果如何。

限制最大工作线程数量

对于ASP.NET 2.0应用程序来说,一个工作线程即为一个客户端请求的处理单位,如果所有工作线程被占完,那么站点就无法处理其他请求。使用异步方式处理请求是ASP.NET 2.0中新增的高级特性,它充分利用操作系统和CLR的功能,使得应用程序在等待IO-Bound操作完成时不会占用线程池中的工作线程(Worker Thread)。关于这一点,我曾经在《正确使用异步操作》一文中进行了较为详细的描述。在CLR 2.0 SP1之后,最大工作线程的数量变成了CPU数 * 250——不过不同托管环境(如IIS或SQL Server),均可有不同体现,而我们的试验很难占用如此多的工作线程,因此进行试验的第一步便是限制应用程序中最大工作线程的数量。在.NET应用程序中,可以通过ThreadPool.SetMaxThreads静态方法设置线程池中最大工作线程数量。

与此同时,我们还应该使用ThreadPool.SetMinThreads方法来设置线程池中“必须保留”的最小线程数量。该值默认为1,它意味着在初始情况下线程池中只保留1个线程。如果同时来访多个请求,那么线程池就必须创建额外的线程。线程池创建线程的最大速度为500毫秒一个,因为实际上一个线程的工作往往能够很快完成,这样线程就能够“复用”了。如果没有这个限制,那么线程池就可能在短时间内分配太多线程反而导致性能降低。当空闲时,线程池也会逐渐销毁线程,以避免系统维护太多线程而导致的多余开销。在我们的试验中,必须马上能够动用足够的工作线程来处理请求,否则就会把大量的时间耗费在等待线程创建上,降低了试验结果的代表性。

ThreadPool.Get/SetMaxThreads方法都会涉及到Complete I/O Port Threads这个值,它在我们试验中并不会影响什么。具体原因目前我也不清楚,原本以为它应该限制了异步IO的数据,但是实验下来却不然。

我们可以使用以下方法来修改线程池中最大及最小线程数量:

void SetThreads(int min, int max)
{
    int worker, io;

    ThreadPool.GetMaxThreads(out worker, out io);
    ThreadPool.SetMinThreads(min, io);
    ThreadPool.SetMaxThreads(max, io);
}

试验同步请求

我的测试环境为Windows Server 2008 x86 Enterprise Edition下的IIS 7。当然,这个试验在IIS 6中也能进行——不过,Vista下的IIS 7限制了10个并发连接数量,因此您无法在Vista下进行这个试验。

我们使用最为普通的工具来进行测试:Tinyget、Powershell以及perfmon。Tinyget是IIS Resource Toolkit中的工具之一,可以用于模拟数量不多的并发请求,常常用于重现一些简单并发环境下出现的问题。Powershell,我们主要是使用它的Measure-Command命令来测试执行一条Tinyget语句所消耗的时间。Measure-Command最简单的语法是Measure-Command {...},其中大括号里包含的是被测量的脚本。permon自然广为人知,我们主要用其来检测ASP.NET Applications\Requests Executing的值,它表示了同时执行请求的数量。

现在我们准备一个Sync.ashx,它将会访问数据库,并执行一个WAITFOR函数,其目的是停留3秒钟:

public class Sync : IHttpHandler
{
    public void ProcessRequest(HttpContext context)
    {
        using (SqlConnection conn = new SqlConnection("..."))
        {
            SqlCommand cmd = new SqlCommand("WAITFOR DELAY '00:00:03';", conn);
            conn.Open();

            cmd.ExecuteNonQuery();
        }

        context.Response.ContentType = "text/plain";
        context.Response.Write("Sync");
    }

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

将最大及最小工作线程数量设为10,20,30,分别执行以下脚本:

Measure-Command {.\tinyget -srv:localhost -uri:/Sync.ashx -threads:30 -loop:1}

tinyget命令threads参数表明同时使用多少个线程进行请求,而loop参数表明“每个线程”将请求多少次。试验结果如下:

Max Worker Threads101520
Max Request Executing61116
Execution Time (s)15.149.106.13
permon Snapshot101010

从试验结果中我们可以发现,可同时执行的请求数比最大工作线程少4(思考题:另外4个在做什么呢?),而同时执行的请求的数量越多,执行所有请求所消耗的时间也在越小。这和我们之前的想法基本一致。

试验异步请求

构建一个异步Handler:

public class Async : IHttpHandler, IHttpAsyncHandler
{
    public void ProcessRequest(HttpContext context) { }

    public bool IsReusable { get { return false; } }

    private SqlConnection m_conn;
    private SqlCommand m_cmd;
    private HttpContext m_context;

    public IAsyncResult BeginProcessRequest(
        HttpContext context, AsyncCallback cb, object extraData)
    {
        this.m_context = context;
        this.m_conn = new SqlConnection("Data Source=...;...;Asynchronous Processing=true");
        this.m_cmd = new SqlCommand("WAITFOR DELAY '00:00:03';", this.m_conn);
        this.m_conn.Open();

        return this.m_cmd.BeginExecuteNonQuery(cb, extraData);
    }

    public void EndProcessRequest(IAsyncResult result)
    {
        this.m_cmd.EndExecuteNonQuery(result);
        this.m_conn.Dispose();

        this.m_context.Response.ContentType = "text/plain";
        this.m_context.Response.Write("Hello World");
    }
}

唯一可能值得提到的是,如果要对SQL Server进行异步数据访问,则必须在连接字符串里加上Asynchronous Processing标记。那么我们把最大和最小工作线程数量设为10个,并使用以下脚本进行测试:

Measure-Command {.\tinyget -srv:localhost -r:7788 -uri:/Sync.ashx -threads:30 -loop:1}
[System.Threading.Thread]::Sleep(2000)
Measure-Command {.\tinyget -srv:localhost -r:7788 -uri:/Async.ashx -threads:30 -loop:1}
[System.Threading.Thread]::Sleep(2000)
Measure-Command {.\tinyget -srv:localhost -r:7788 -uri:/Async.ashx -threads:40 -loop:1}
[System.Threading.Thread]::Sleep(2000)
Measure-Command {.\tinyget -srv:localhost -r:7788 -uri:/Async.ashx -threads:50 -loop:1}

上述脚本首先将同时发起30次同步请求,再发起三次异步请求,数目分别是30、40和50。试验结果如下:

Max Request Executing6304050
Execution Time (s)15.063.103.113.10
permon Snapshot10

结果再明显不过了:应用程序还是只能每次处理6个同步请求,但是对于异步请求来说似乎就“丝毫不受限制”了。为了更好的说明问题,我们再进行最后一个试验。

降低最小线程数量

之前提过,最小线程数量代表了线程池中所维护的最少线程数量。线程池将会根据需要来创建或销毁线程。

我们现在将最小线程数量设为1,最大线程数量设为20,使用同时发起50个请求。试验结果如下:

Max Request Executing950
Execution Time (s)18.273.37
perfmon Snapshotmin-syncmin-async

对于同步请求,同时处理的请求数目从1开始以每秒两个的速度增长,最终受限于“保护机制”而停止在9个线程。而对于异步请求,则是瞬间飙升至50个——因为这样的请求不需要占用工作线程,自然无需等待线程慢慢分配了。

看了以上的试验,不知道您是否有所感受?不如您也在自己的机器上试试看呢?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值