新聞中心
在前文中,介紹了.NET下的多種異步的形式,在WEB程序中,天生就是多線程的,因此使用異步應該更為謹慎。本文將著重展開ASP.NET中的異步。

創(chuàng)新互聯(lián)成立于2013年,是專業(yè)互聯(lián)網(wǎng)技術服務公司,擁有項目成都網(wǎng)站建設、網(wǎng)站設計網(wǎng)站策劃,項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命,1280元南部做網(wǎng)站,已為上家服務,為南部各地企業(yè)和個人服務,聯(lián)系電話:13518219792
【注意】本文中提到的異步指的是服務器端異步,而非客戶端異步(Ajax)。
對于HTTP的請求響應模型,服務器無法主動通知或回調客戶端,當客戶端發(fā)起一個請求后,必須保持連接等待服務器的返回結果,才能繼續(xù)處理,因此,對于客戶端來說,請求與響應是無法異步進行,也就是說無論服務器如何處理請求,對于客戶端來說沒有任何差別。
那么ASP.NET異步指的又是什么,解決了什么問題呢?
在解釋ASP.NET異步前,先來考察下ASP.NET線程模型。
ASP.NET線程模型
我們知道,一個WEB服務可以同時服務器多個用戶,我們可以想象一下,WEB程序應該運行于多線程環(huán)境中,對于運行WEB程序的線程,我們可以稱之為WEB線程,那么,先來看看WEB線程長什么樣子吧。
我們可以用一個HttpHandler輸出一些內(nèi)容。
- public class Handler : IHttpHandler
- {
- public void ProcessRequest(HttpContext context)
- {
- context.Response.ContentType = "text/plain";
- var thread = Thread.CurrentThread;
- context.Response.Write(
- string.Format("Name:{0}\r\nManagedThreadId:{1}\r\nIsBackground:{2}\r\nIsThreadPoolThread:{3}",
- thread.Name,
- thread.ManagedThreadId,
- thread.IsBackground,
- thread.IsThreadPoolThread)
- );
- }
- public bool IsReusable
- {
- get {return true;}
- }
- }
你可以看到類似于這樣的結果:
Name:
ManagedThreadId:57
IsBackground:True
IsThreadPoolThread:True
這里可以看到,WEB線程是一個沒有名稱的線程池中的線程,如果刷新這個頁面,還有機會看到 ManagedThreadId 在不斷變化,并且可能重復出現(xiàn)。說明WEB程序有機會運行于線程池中的不同線程。
為了模擬多用戶并發(fā)訪問的情況,我們需要對這個處理程序添加人為的延時,并輸出線程相關信息與開始結束時間,再通過客戶端程序同時發(fā)起多個請求,查看返回的內(nèi)容,分析請求的處理情況。
- public void ProcessRequest(HttpContext context)
- {
- DateTime begin = DateTime.Now;
- int t1, t2, t3;
- ThreadPool.GetAvailableThreads(out t1, out t3);
- ThreadPool.GetMaxThreads(out t2, out t3);
- Thread.Sleep(TimeSpan.FromSeconds(10));
- DateTime end = DateTime.Now;
- context.Response.ContentType = "text/plain";
- var thread = Thread.CurrentThread;
- context.Response.Write(
- string.Format("TId:{0}\tApp:{1}\tBegin:{2:mm:ss,ffff}\tEnd:{3:mm:ss,ffff}\tTPool:{4}",
- thread.ManagedThreadId,
- context.ApplicationInstance.GetHashCode(),
- begin,
- end,
- t2 - t1
- )
- );
- }
我們用一個命令行程序來發(fā)起請求,并顯示結果。
- static void Main()
- {
- var url = new Uri("http://localhost:8012/Handler.ashx");
- var num = 50;
- for (int i = 0; i < num; i++)
- {
- var request = WebRequest.Create(url);
- request.GetResponseAsync().ContinueWith(t =>
- {
- var stream = t.Result.GetResponseStream();
- using (TextReader tr = new StreamReader(stream))
- {
- Console.WriteLine(tr.ReadToEnd());
- }
- });
- }
- Console.ReadLine();
- }
這里,我們同時發(fā)起了50個請求,然后觀察響應的情況。
【注意】后面的結果會因為操作系統(tǒng)、IIS版本、管道模式、.NET版本、配置項 的不同而不同,以下結果為在Windows Server 2008 R2 + IIS7.5 + .NET 4.5 beta(.NET 4 runtime) + 默認配置 中測試的結果,在沒有特別說明的情況下,均為重啟IIS后第一次運行的情況。
這個程序在我的電腦運行結果是這樣的:
- TId:6 App:35898671 Begin:55:30,3176 End:55:40,3182 TPool:2
- TId:5 App:22288629 Begin:55:30,3176 End:55:40,3212 TPool:2
- TId:7 App:12549444 Begin:55:31,0426 End:55:41,0432 TPool:3
- TId:8 App:22008501 Begin:55:31,5747 End:55:41,5752 TPool:4
- TId:9 App:37121646 Begin:55:32,1067 End:55:42,1073 TPool:5
- TId:10 App:33156464 Begin:55:32,6387 End:55:42,6393 TPool:6
- TId:11 App:7995840 Begin:55:33,1707 End:55:43,1713 TPool:7
- TId:12 App:36610825 Begin:55:33,7028 End:55:43,7033 TPool:8
- TId:13 App:20554616 Begin:55:34,2048 End:55:44,2054 TPool:9
- TId:14 App:15510466 Begin:55:35,2069 End:55:45,2074 TPool:10
- TId:15 App:23324256 Begin:55:36,2049 End:55:46,2055 TPool:11
- TId:16 App:34250480 Begin:55:37,2050 End:55:47,2055 TPool:12
- TId:17 App:58408916 Begin:55:38,2050 End:55:48,2056 TPool:13
- TId:18 App:2348279 Begin:55:39,2051 End:55:49,2057 TPool:14
- TId:19 App:61669314 Begin:55:40,2051 End:55:50,2057 TPool:15
- TId:6 App:35898671 Begin:55:40,3212 End:55:50,3217 TPool:15
- TId:5 App:22288629 Begin:55:40,3232 End:55:50,3237 TPool:15
- TId:7 App:12549444 Begin:55:41,0432 End:55:51,0438 TPool:15
- TId:8 App:22008501 Begin:55:41,5752 End:55:51,5758 TPool:15
- TId:9 App:37121646 Begin:55:42,1073 End:55:52,1078 TPool:15
- TId:10 App:33156464 Begin:55:42,6393 End:55:52,6399 TPool:15
- TId:11 App:7995840 Begin:55:43,1713 End:55:53,1719 TPool:15
- TId:12 App:36610825 Begin:55:43,7043 End:55:53,7049 TPool:15
- TId:13 App:20554616 Begin:55:44,2054 End:55:54,2059 TPool:15
- TId:20 App:36865354 Begin:55:45,2074 End:55:55,2080 TPool:16
- TId:14 App:15510466 Begin:55:45,2084 End:55:55,2090 TPool:16
- TId:21 App:3196068 Begin:55:46,2055 End:55:56,2061 TPool:17
- TId:15 App:23324256 Begin:55:46,2065 End:55:56,2071 TPool:17
- TId:22 App:4186222 Begin:55:47,2055 End:55:57,2061 TPool:18
- TId:16 App:34250480 Begin:55:47,2065 End:55:57,2071 TPool:18
- TId:23 App:764807 Begin:55:48,2046 End:55:58,2052 TPool:19
- TId:17 App:58408916 Begin:55:48,2056 End:55:58,2062 TPool:19
- TId:24 App:10479095 Begin:55:49,2047 End:55:59,2052 TPool:20
- TId:18 App:2348279 Begin:55:49,2057 End:55:59,2062 TPool:20
- TId:25 App:4684807 Begin:55:50,2047 End:56:00,2053 TPool:21
- TId:19 App:61669314 Begin:55:50,2057 End:56:00,2063 TPool:21
- TId:6 App:35898671 Begin:55:50,3227 End:56:00,3233 TPool:21
- TId:5 App:22288629 Begin:55:50,3237 End:56:00,3243 TPool:21
- TId:7 App:12549444 Begin:55:51,0438 End:56:01,0443 TPool:21
- TId:8 App:22008501 Begin:55:51,5758 End:56:01,5764 TPool:21
- TId:9 App:37121646 Begin:55:52,1078 End:56:02,1084 TPool:21
- TId:10 App:33156464 Begin:55:52,6399 End:56:02,6404 TPool:21
- TId:11 App:7995840 Begin:55:53,1719 End:56:03,1725 TPool:21
- TId:26 App:41662089 Begin:55:53,7049 End:56:03,7055 TPool:22
- TId:12 App:36610825 Begin:55:53,7059 End:56:03,7065 TPool:22
- TId:13 App:20554616 Begin:55:54,2069 End:56:04,2075 TPool:22
- TId:27 App:46338128 Begin:55:55,2070 End:56:05,2076 TPool:23
- TId:14 App:15510466 Begin:55:55,2090 End:56:05,2096 TPool:23
- TId:20 App:36865354 Begin:55:55,2090 End:56:05,2096 TPool:23
- TId:28 App:28975576 Begin:55:56,2051 End:56:06,2056 TPool:24
從這個結果大概可以看出,開始兩個請求幾乎同時開始處理,因為線程池最小線程數(shù)為2(可配置),緊接著后面的請求會每隔半秒鐘開始一個,因為如果池中的線程都忙,會等待半秒(.NET版本不同而不同),如果還是沒有線程釋放則開啟新的線程,直到達到最大線程數(shù)(可配置)。未能在線程池中處理的請求將被放入請求隊列,當一個線程釋放后,下一個請求緊接著開始在該線程處理。
最終50個請求共產(chǎn)生24個線程,總用時約35.9秒。
光看數(shù)據(jù)不夠形象,用簡單的代碼把數(shù)據(jù)轉換成圖形吧,下面是100個請求的處理過程。
我們可以看到,當WEB線程長時間被占用時,請求會由于線程池而阻塞,同時產(chǎn)生大量的線程,最終響應時間變長。
作為對比,我們列出處理時間10毫秒的數(shù)據(jù)。
- TId:6 App:44665200 Begin:41:07,9932 End:41:08,0032 TPool:2
- TId:5 App:37489757 Begin:41:07,9932 End:41:08,0032 TPool:2
- TId:5 App:44665200 Begin:41:08,0042 End:41:08,0142 TPool:2
- TId:6 App:37489757 Begin:41:08,0052 End:41:08,0152 TPool:2
- TId:5 App:44665200 Begin:41:08,0142 End:41:08,0242 TPool:2
- TId:6 App:37489757 Begin:41:08,0152 End:41:08,0252 TPool:2
- TId:5 App:44665200 Begin:41:08,0242 End:41:08,0342 TPool:2
- TId:6 App:37489757 Begin:41:08,0252 End:41:08,0352 TPool:2
- TId:5 App:44665200 Begin:41:08,0342 End:41:08,0442 TPool:2
- TId:6 App:37489757 Begin:41:08,0352 End:41:08,0452 TPool:2
- TId:5 App:44665200 Begin:41:08,0442 End:41:08,0542 TPool:2
- TId:6 App:37489757 Begin:41:08,0452 End:41:08,0552 TPool:2
- TId:5 App:44665200 Begin:41:08,0542 End:41:08,0642 TPool:2
- TId:6 App:37489757 Begin:41:08,0552 End:41:08,0652 TPool:2
- TId:5 App:44665200 Begin:41:08,0642 End:41:08,0742 TPool:2
- TId:6 App:37489757 Begin:41:08,0652 End:41:08,0752 TPool:2
- TId:5 App:44665200 Begin:41:08,0742 End:41:08,0842 TPool:2
- TId:6 App:37489757 Begin:41:08,0752 End:41:08,0852 TPool:2
- TId:5 App:44665200 Begin:41:08,0842 End:41:08,0942 TPool:2
- TId:6 App:37489757 Begin:41:08,0852 End:41:08,0952 TPool:2
- TId:5 App:44665200 Begin:41:08,0942 End:41:08,1042 TPool:2
- TId:6 App:37489757 Begin:41:08,0952 End:41:08,1052 TPool:2
- TId:5 App:44665200 Begin:41:08,1042 End:41:08,1142 TPool:2
- TId:6 App:37489757 Begin:41:08,1052 End:41:08,1152 TPool:2
- TId:5 App:44665200 Begin:41:08,1142 End:41:08,1242 TPool:2
- TId:6 App:37489757 Begin:41:08,1152 End:41:08,1252 TPool:2
- TId:5 App:44665200 Begin:41:08,1242 End:41:08,1342 TPool:2
- TId:6 App:37489757 Begin:41:08,1252 End:41:08,1352 TPool:2
- TId:5 App:44665200 Begin:41:08,1342 End:41:08,1442 TPool:2
- TId:6 App:37489757 Begin:41:08,1352 End:41:08,1452 TPool:2
- TId:5 App:44665200 Begin:41:08,1442 End:41:08,1542 TPool:2
- TId:6 App:37489757 Begin:41:08,1452 End:41:08,1552 TPool:2
- TId:5 App:44665200 Begin:41:08,1542 End:41:08,1642 TPool:2
- TId:6 App:37489757 Begin:41:08,1552 End:41:08,1652 TPool:2
- TId:5 App:44665200 Begin:41:08,1642 End:41:08,1742 TPool:2
- TId:6 App:37489757 Begin:41:08,1652 End:41:08,1752 TPool:2
- TId:5 App:44665200 Begin:41:08,1742 End:41:08,1842 TPool:3
- TId:7 App:12547953 Begin:41:08,1752 End:41:08,1852 TPool:3
- TId:6 App:37489757 Begin:41:08,1762 End:41:08,1862 TPool:3
- TId:5 App:44665200 Begin:41:08,1842 End:41:08,1942 TPool:3
- TId:7 App:12547953 Begin:41:08,1852 End:41:08,1952 TPool:3
- TId:6 App:37489757 Begin:41:08,1862 End:41:08,1962 TPool:3
- TId:5 App:44665200 Begin:41:08,1942 End:41:08,2042 TPool:3
- TId:7 App:12547953 Begin:41:08,1952 End:41:08,2092 TPool:3
- TId:6 App:37489757 Begin:41:08,1962 End:41:08,2102 TPool:3
- TId:5 App:44665200 Begin:41:08,2052 End:41:08,2152 TPool:3
- TId:7 App:12547953 Begin:41:08,2092 End:41:08,2192 TPool:3
- TId:6 App:37489757 Begin:41:08,2102 End:41:08,2202 TPool:3
- TId:5 App:44665200 Begin:41:08,2152 End:41:08,2252 TPool:3
- TId:7 App:12547953 Begin:41:08,2192 End:41:08,2292 TPool:3
共產(chǎn)生線程3個,總用時0.236秒。
根據(jù)以上的數(shù)據(jù),我們可以得出結論,要提高系統(tǒng)響應時間與并發(fā)處理數(shù),應盡可能減少WEB線程的等待。
【略】請各位自行查驗當一次并發(fā)全部處理完畢后再次測試的處理情況。
【略】請各位自行查驗當處理程序中使用線程池處理等待任務的處理情況。
如何減少WEB線程的等待呢,那就應該盡早的結果ProcessRequest方法,前一篇中講到,對于一些需要等待完成的任務,可以使用異步方法來做,于是我們可以在ProcessRequest中調用異步方法,但問題是當ProcessRequest結束后,請求處理也即將結束,一但請求結束,將沒有辦法在這一次請求中返回結果給客戶端,但是此時,異步任務還沒有完成,當異步任務完成時,也許再也沒有辦法將結果傳給客戶端了。(難道用輪詢?囧)
我們需要的方案是,處理請求時可以暫停處理(不是暫停線程),并保持客戶端連接,在需要時,向客戶端輸出結果,并結束請求。
在這個模型中,可以看到,對于WebServerRuntime來說,我們的請求處理程序就是一個異步方法,而對于客戶端來說,卻并不知道后面的處理情況。無論在WebServerRuntime或是我們的處理程序,都沒有直接占用線程,一切由何時SetComplete決定。同時可以看到,這種模式需要WebServerRuntime的緊密配合,提供調用異步方法的接口。在ASP.NET中,這個接口就是IHttpAsyncHandler。
異步ASP.NET處理程序
首先,我們來實現(xiàn)第一個異步處理程序,在適當?shù)臅r候觸發(fā)結束,在開始和結束時輸出一些信息。
- public class Handler : IHttpHandler, IHttpAsyncHandler
- {
- public void ProcessRequest(HttpContext context)
- {
- //異步處理器不執(zhí)行該方法
- }
- public bool IsReusable
- {
- //設置允許重用對象
- get { return false; }
- }
- //請求開始時由ASP.NET調用此方法
- public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
- {
- context.Response.ContentType = "text/xml";
- context.Response.Write("App:");
- context.Response.Write(context.ApplicationInstance.GetHashCode());
- context.Response.Write("\tBegin:");
- context.Response.Write(DateTime.Now.ToString("mm:ss,ffff"));
- //輸出當前線程
- context.Response.Write("\tThreadId:");
- context.Response.Write(Thread.CurrentThread.ManagedThreadId);
- //構建異步結果并返回
- var result = new WebAsyncResult(cb, context);
- //用一個定時器來模擬異步觸發(fā)完成
- Timer timer = null;
- timer = new Timer(o =>
- {
- result.SetComplete();
- timer.Dispose();
- }, null, TimeSpan.FromSeconds(5), TimeSpan.FromSeconds(5));
- return result;
- }
- //異步結束時,由ASP.NET調用此方法
- public void EndProcessRequest(IAsyncResult result)
- {
- WebAsyncResult webresult = (WebAsyncResult)result;
- webresult.Context.Response.Write("\tEnd:");
- webresult.Context.Response.Write(DateTime.Now.ToString("mm:ss,ffff"));
- //輸出當前線程
- webresult.Context.Response.Write("\tThreadId:");
- webresult.Context.Response.Write(Thread.CurrentThread.ManagedThreadId);
- }
- //WEB異步方法結果
- class WebAsyncResult : IAsyncResult
- {
- private AsyncCallback _callback;
- public WebAsyncResult(AsyncCallback cb, HttpContext context)
- {
- Context = context;
- _callback = cb;
- }
- //當異步完成時調用該方法
- public void SetComplete()
- {
- IsCompleted = true;
- if (_callback != null)
- {
- _callback(this);
- }
- }
- public HttpContext Context
- {
- get;
- private set;
- }
- public object AsyncState
- {
- get { return null; }
- }
- //由于ASP.NET不會等待WEB異步方法,所以不使用此對象
- public WaitHandle AsyncWaitHandle
- {
- get { throw new NotImplementedException(); }
- }
- public bool CompletedSynchronously
- {
- get { return false; }
- }
- public bool IsCompleted
- {
- get;
- private set;
- }
- }
- }
在這里,我們實現(xiàn)了一個簡單的AsyncResult,由于ASP.NET通過回調方法獲取異步完成,不會等待異步,所以不需要WaitHandle。在開始請求時,建立一個AsyncResult后直接返回,當異步完成時,調用AsyncResult的SetComplete方法,調用回調方法,再由 ASP.NET調用異步結束。此時整個請求即完成。
當我們訪問這個地址,可以得到類似于下面的結果:
App:11240144 Begin:37:24,2676 ThreadId:6 End:37:29,2619 ThreadId:6
可以看到開始和結束在同一個線程中運行。
當有多個并發(fā)請求時,線程池將忙碌起來,開始與結束處理也獎有機會運行于不同的線程上。50個請求并發(fā)時的處理數(shù)據(jù):
- App:52307948 Begin:39:47,8128 ThreadId:6 End:39:52,8231 ThreadId:5
- App:58766839 Begin:39:47,8358 ThreadId:5 End:39:52,8321 ThreadId:7
- App:23825510 Begin:39:47,8348 ThreadId:5 End:39:52,8321 ThreadId:7
- App:30480920 Begin:39:47,8348 ThreadId:5 End:39:52,8321 ThreadId:7
- App:62301924 Begin:39:47,8348 ThreadId:6 End:39:52,8321 ThreadId:6
- App:28062782 Begin:39:47,8338 ThreadId:5 End:39:52,8321 ThreadId:6
- App:41488021 Begin:39:47,8338 ThreadId:6 End:39:52,8321 ThreadId:7
- App:15315213 Begin:39:47,8338 ThreadId:6 End:39:52,8321 ThreadId:6
- App:17228638 Begin:39:47,8328 ThreadId:5 End:39:52,8321 ThreadId:7
- App:51438283 Begin:39:47,8328 ThreadId:6 End:39:52,8321 ThreadId:6
- App:32901400 Begin:39:47,8328 ThreadId:5 End:39:52,8321 ThreadId:7
- App:61925337 Begin:39:47,8358 ThreadId:6 End:39:52,8321 ThreadId:6
- App:24914721 Begin:39:47,8318 ThreadId:6 End:39:52,8321 ThreadId:6
- App:26314214 Begin:39:47,8318 ThreadId:6 End:39:52,8321 ThreadId:6
- App:51004322 Begin:39:47,8358 ThreadId:6 End:39:52,8321 ThreadId:6
- App:51484875 Begin:39:47,8308 ThreadId:5 End:39:52,8321 ThreadId:7
- App:19420176 Begin:39:47,8308 ThreadId:6 End:39:52,8321 ThreadId:6
- App:16868352 Begin:39:47,8298 ThreadId:6 End:39:52,8321 ThreadId:7
- App:61115195 Begin:39:47,8298 ThreadId:5 End:39:52,8321 ThreadId:6
- App:63062333 Begin:39:47,8288 ThreadId:6 End:39:52,8321 ThreadId:6
- App:53447344 Begin:39:47,8298 ThreadId:5 End:39:52,8321 ThreadId:7
- App:31665793 Begin:39:47,8288 ThreadId:5 End:39:52,8321 ThreadId:7
- App:2174563 Begin:39:47,8288 ThreadId:6 End:39:52,8321 ThreadId:6
- App:12053474 Begin:39:47,8318 ThreadId:5 End:39:52,8321 ThreadId:7
- App:41728762 Begin:39:47,8278 ThreadId:6 End:39:52,8321 ThreadId:6
- App:6385742 Begin:39:47,8278 ThreadId:5 End:39:52,8321 ThreadId:7
- App:13009416 Begin:39:47,8268 ThreadId:6 End:39:52,8321 ThreadId:6
- App:43205102 Begin:39:47,8268 ThreadId:5 End:39:52,8321 ThreadId:7
- App:14333193 Begin:39:47,8268 ThreadId:6 End:39:52,8321 ThreadId:6
- App:2808346 Begin:39:47,8258 ThreadId:6 End:39:52,8321 ThreadId:6
- App:37489757 Begin:39:47,8128 ThreadId:5 End:39:52,8231 ThreadId:6
- App:34106743 Begin:39:47,8258 ThreadId:5 End:39:52,8321 ThreadId:7
- App:30180123 Begin:39:47,8248 ThreadId:6 End:39:52,8321 ThreadId:6
- App:44313942 Begin:39:47,8248 ThreadId:5 End:39:52,8321 ThreadId:7
- App:12611187 Begin:39:47,8248 ThreadId:6 End:39:52,8321 ThreadId:6
- App:7141266 Begin:39:47,8238 ThreadId:5 End:39:52,8321 ThreadId:7
- App:25425822 Begin:39:47,8278 ThreadId:5 End:39:52,8321 ThreadId:7
- App:51288387 Begin:39:47,8238 ThreadId:5 End:39:52,8321 ThreadId:7
- App:66166301 Begin:39:47,8228 ThreadId:6 End:39:52,8321 ThreadId:6
- App:34678979 Begin:39:47,8228 ThreadId:6 End:39:52,8321 ThreadId:7
- App:10104599 Begin:39:47,8218 ThreadId:5 End:39:52,8321 ThreadId:6
- App:47362231 Begin:39:47,8258 ThreadId:5 End:39:52,8321 ThreadId:7
- App:40535505 Begin:39:47,8218 ThreadId:6 End:39:52,8321 ThreadId:7
- App:20726372 Begin:39:47,8368 ThreadId:5 End:39:52,8321 ThreadId:5
- App:2730334 Begin:39:47,8368 ThreadId:6 End:39:52,8321 ThreadId:6
- App:59884855 Begin:39:47,8368 ThreadId:5 End:39:52,8321 ThreadId:7
- App:39774547 Begin:39:47,8238 ThreadId:6 End:39:52,8321 ThreadId:6
- App:12070837 Begin:39:47,8378 ThreadId:6 End:39:52,8491 ThreadId:7
- App:64828693 Begin:39:47,8218 ThreadId:5 End:39:52,8331 ThreadId:6
- App:14509978 Begin:39:47,9308 ThreadId:6 End:39:52,9281 ThreadId:5
可以看到,從始至終只由3個線程處理所有的請求,總共時間約5.12秒。
為簡化分析,我們用下面的圖來示意異步處理程序的并發(fā)處理過程。
這樣,我們就可以通過異步的方式,將WEB線程撤底釋放出來。由WEB線程進行請求的接收與結束處理,耗時的操作與等待都進行異步處理。這樣少量的WEB線程就可以承受大量的并發(fā)請求,WEB線程將不再成為系統(tǒng)的瓶頸。
在大并發(fā)的異步模式下,和前面的數(shù)據(jù)相比較,可以看到HttpApplication的對象數(shù)量隨并發(fā)處理數(shù)提高而提高,隨之帶來的一系列數(shù)據(jù)結構,如 HttpHandler緩存,是需要考慮的內(nèi)存開銷。同時,在異步模式下,請求的完成需要編程的方式來控制,在觸發(fā)完成前,客戶端連接、 HttpContext對象都保持活動狀態(tài),客戶端也一直保持等待,直到超時。因此,異步模式下需要更細致的資源操作。
我們來看ASP.NET異步 的典型應用場景。
場景一:處理過程中有需要等待的任務,并且可以使用異步完成的。
- //同步方法
- public void ProcessRequest(HttpContext context)
- {
- FileStream fs = new FileStream("", FileMode.Open, FileAccess.Read, FileShare.ReadWrite, 4096, FileOptions.Asynchronous);
- fs.CopyTo(context.Response.OutputStream);
- }
- //異步方法開始
- public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
- {
- FileStream fs = new FileStream("D:\\a.txt", FileMode.Open, FileAccess.Read, FileShare.ReadWrite, 4096, FileOptions.Asynchronous);
- var task = fs.CopyToAsync(context.Response.OutputStream);
- task.GetAwaiter().OnCompleted(() => cb(task));
- return task;
- }
- //異步方法結束
- public void EndProcessRequest(IAsyncResult result)
- {
- }
這個處理程序讀取服務器的文件并輸出到客戶端。
- //同步方法
- public void ProcessRequest(HttpContext context)
- {
- var url = context.Request.QueryString["url"];
- var request = (HttpWebRequest)WebRequest.Create(url);
- var response = request.GetResponse();
- var stream = response.GetResponseStream();
- stream.CopyTo(context.Response.OutputStream);
- }
- //異步方法開始
- public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
- {
- //構建異步結果并返回
- var result = new WebAsyncResult(cb, context);
- var url = context.Request.QueryString["url"];
- var request = (HttpWebRequest)WebRequest.Create(url);
- var responseTask = request.GetResponseAsync();
- responseTask.GetAwaiter().OnCompleted(() =>
- {
- var stream = responseTask.Result.GetResponseStream();
- stream.CopyToAsync(context.Response.OutputStream).GetAwaiter().OnCompleted(() =>
- {
- result.SetComplete();
- });
- });
- return result;
- }
- //異步方法結束
- public void EndProcessRequest(IAsyncResult result)
- {
- }
這是一個簡單的代理,服務器獲取WEB資源后寫回。
在這類程序中,我們提供的異步處理程序調用了IOCP異步方法,使得大量節(jié)省了WEB線程的占用,相比同步處理程序來說,并發(fā)量會得到相當大的提升。
【注意】前面提到,由于WEB線程屬于線程池線程,因此,如果在線程池中加入任務,將同樣會影響并發(fā)處理數(shù)。而在異步處理程序中,由線程池來完成異步將得不到任何本質上的提升,因此在異步處理程序中禁止操作線程池(ThreadPool.QueueUserWorkItem、 delegate.BeginInvoke,Task.Run等)。如果確定需要使用多線程來處理大量的計算,需要自己開啟線程或實現(xiàn)自己的線程池。
- public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
- {
- return new Action(() =>
- {
- Thread.Sleep(1000);
- context.Response.Write("OK");
- }).BeginInvoke(cb, extraData);
- }
上面的代碼將無法達到異步的效果。
雖然等待工作交由另一線程去操作,但是該線程與WEB線程性質相同,同樣會導致其他請求阻塞。
【思考】如果我們的程序中的確需要有大量的計算,那么可以考慮將這些計算提取到獨立的應用服務器中,然后通過網(wǎng)絡IOCP異步調用,達到WEB服務器的高吞吐量與系統(tǒng)的平行擴展性。
典型應用場景二:長連
分享題目:詳細解讀ASP.NET的異步
網(wǎng)站地址:http://m.fisionsoft.com.cn/article/dpdiicp.html


咨詢
建站咨詢
