推薦：ASP錯誤大全
ASP錯誤大全 對初學(xué)者們有幫助,或許高手也會忘記,ASP錯誤大全 MicrosoftVBScript語*錯誤(0x800A03E9)-->內(nèi)存不足 MicrosoftVBScript語*錯誤(0x800A03EA)-->語*錯誤 MicrosoftVBScript語*

ASP請求由WAM對象進行初始化處理。該WAM對象再把它發(fā)送給ASP-RunTime。ASP-RunTime通過創(chuàng)建一個內(nèi)部頁面對象對其進行響應(yīng)。

WAM對象是一個自由線程對象。當(dāng)它調(diào)用諸如ASP.DLL的ISAPI擴展時，它使用由IIS-RunTime維護的線程池所分配的MTA模型的線程。

創(chuàng)建ISAPI擴展時面對的一個棘手的問題是，如何處理由這一MTA線程池所帶來的線程并發(fā)與同步的問題。ASP-RunTime通過在運行ASP腳本前把每個ASP請求切換至一個單線程單元(STA)，從而使問題得到簡化。ASP-RunTime管理一個獨立的STA輔助線程池(在后臺，ASP實際上通過使用COM 線程池來實現(xiàn)這一點)。ASP設(shè)計師創(chuàng)建了這種線程池方案，以在并發(fā)和資源利用之間提供一種優(yōu)化平衡，同時消除對程序員實現(xiàn)同步的需要。


ASP-RunTime是怎樣把每個請求從MTA線程切換到STA線程的。ASP-RunTime調(diào)度機制把每個請求都放到一個中央請求隊列中。由ASP管理的線程池中的STA線程監(jiān)視該隊列并以先進先出方式處理請求。注意，這一線程池的大小是動態(tài)變化的。ASP-RunTime在通信高峰期會產(chǎn)生額外的線程，而在通信較少時釋放線程。

切換到STA線程有效地解決了并發(fā)性問題，但是這樣對于性能也有明顯的影響。在一個單獨的MTA線程中隊每個請求進行處理的ISAPI擴展DLL都能提供更快的響應(yīng)時間。

IIS提供了一種方法以對STA線程池和請求隊列的最大尺寸進行設(shè)置。線程池的大小由IIS元數(shù)據(jù)庫中AspProcessorThreadMax主鍵控制。該主鍵的缺省設(shè)置是每進程每處理器25（評論：此數(shù)字最好能找到微軟的相關(guān)文檔證明一下。有人說這個數(shù)目是10個/CPU）。也就是說，在一臺四處理器計算機中，每個處理ASP的進程可以最多有100個輔助線程。除非對調(diào)整線程池的相關(guān)問題已經(jīng)考慮成熟，否則應(yīng)該避免改變該鍵值。注意，你不能使用Internet Server Manager來改變這個設(shè)置。必須使用管理腳本或者VB應(yīng)用來進行修改。

IIS為ASP請求隊列設(shè)置了一個最大容量。缺省情況下，ASP-RunTime允許隊列最多容納3000個請求（微軟的另一篇文檔指出，這個隊列只能容納500個請求）。一旦超出，后來進入的ASP請求就會被拒絕，返回錯誤信息為“Server Too Busy”。

可以使用IIS管理對象和ADSI來編程修改AspProcessorThreadMax主鍵和AspRequestQueueMax主鍵。例如，在一個Standard EXE項目中，引用Active DS類型庫，編寫如下代碼：

Dim MyWebServer As ActiveDS.IADs

Set MyWebServer = GetOject(“IIS://Localhost/W3SVC”)

MyWebServer.Put “AspProcessorThreadMax”, 30

MyWebServer.Put “AspRequestQueueMax”, 1500

MyWebServer.SetInfo



下面簡單總結(jié)一下在單處理器計算機上以缺省方式安裝的IIS中，ASP線程池是怎么工作的。該線程池對于每個處理器有25個STA輔助線程可用。當(dāng)一個請求到達(dá)時，就被放到請求隊列中，ASP-RunTime從線程池中調(diào)度一個空閑STA線程，如果存在一個可用的話（注意，這種方案允許線程池中的任何線程都可以對請求進行處理）。如果沒有空閑的輔助線程，請求就加入隊列。只要隊列沒有達(dá)到缺省最大容量，所有請求都將得到處理。

來自Ted Pattison的《Programming Distributed Application with Visual Basic 6.0》

分享：ASP的技術(shù)特點與使用方法
幾年以前,業(yè)界在動態(tài)主頁發(fā)布方面唯一的渠道是CGI(Common Ga teway Interface) 模式。隨后出現(xiàn)的 ISAPI、NSAPI和JDBC等技術(shù)方案雖較CGI進步,但從企業(yè)網(wǎng)(Intranet )的技術(shù)現(xiàn)實來衡量,這些方案仍