服務(wù)熱線
153 8323 9821
情況:從 ASP.NET 頁面調(diào)用 Web 服務(wù)時的性能破壞
我們在本專欄中討論 Web 服務(wù)時,期望在各種情況下都可以享用 Web 服務(wù)。一個主要的情況是從中間層環(huán)境(如 ASP.NET Web 頁面)訪問 Web 服務(wù)。為 MapPoint .NET Web 服務(wù)的用戶提供支持的人員經(jīng)常收到這樣的問題,即用戶在使用其 Web 服務(wù)時,對 MapPoint .NET 的調(diào)用可能需要相當(dāng)長的時間。這本身并不是什么問題,但某些其他因素可以使之成為比表面上要嚴(yán)重得多的大問題。
HTTP 雙連接限制
HTTP 規(guī)范表明,一個 HTTP 客戶端與任一服務(wù)器最多可以同時建立兩個 TCP 連接。這可以防止單個瀏覽器在瀏覽某個頁面(例如,具有 120 個嵌入的縮略圖)時,由于連接請求過多而使服務(wù)器負(fù)載過重。此時,瀏覽器將僅創(chuàng)建 2 個連接,然后通過這兩個管道開始發(fā)送 120 個 HTTP 請求,而不是創(chuàng)建 120 個 TCP 連接并通過每個連接來發(fā)送 HTTP 請求。對于中間層,此方法的問題在于,中間層可能會有 50 個同時請求連接的用戶。如果不得不為每個用戶進(jìn)行一次 MapPoint .NET Web 服務(wù)調(diào)用,將會有 48 個用戶等待兩個管道中的一個空閑下來。
線程池限制
ASP.NET 處理傳入的請求的方式是通過一個稱為進(jìn)程線程池的一組線程為其提供服務(wù)。正常情況下,請求傳入后,池中某個空閑的線程將為其提供服務(wù)。這里的問題在于,進(jìn)程線程池不會創(chuàng)建無數(shù)個線程來處理大量的請求。具有最大線程數(shù)限制是一件好事,因為如果我們無限地創(chuàng)建線程,計算機(jī)上的全部資源將只能用來管理這些線程了。通過限制所能創(chuàng)建的線程數(shù),我們可以把線程管理的系統(tǒng)開銷保持在一個可控的水平。如果某個請求傳入時線程池中的所有線程都被占用,則該請求將排隊等候,在忙線程完成任務(wù)后,空閑出來的線程才能處理新請求。此方法實際上比切換到某個新線程更有效,因為不需要在請求之間進(jìn)行線程切換。但存在的問題是,如果線程的使用效率不高(尤其是在非常忙的 Web 服務(wù)器上),則等候的請求隊列會變得很大。
考慮一下從 ASP.NET 頁面進(jìn)行 Web 服務(wù)調(diào)用的情況。如果進(jìn)行同步調(diào)用,則正在運(yùn)行的線程將被阻塞,直到 Web 服務(wù)調(diào)用完成為止。在調(diào)用期間,線程無法進(jìn)行任何其他活動。它無法處理其他請求,只能等待。如果某個單處理器計算機(jī)上具有默認(rèn)的工作線程數(shù) 20,則只需 20 個同時進(jìn)行的請求即可用完全部線程,以后的請求必須排隊等候。
該問題不僅限于 Web 服務(wù)
不僅調(diào)用 Web 服務(wù)的用戶會遇到從 Web 頁面進(jìn)行調(diào)用時的擁堵且耗時較長的問題。進(jìn)行任意數(shù)量的較長的調(diào)用都會遇到同樣的問題,例如:SQL Server™ 請求、長文件的讀取或?qū)懭?、各種 Web 請求或訪問某個并發(fā)資源(其中鎖定會造成嚴(yán)重的延遲)。實際上,有許多使用 Web 服務(wù)的情況,其服務(wù)調(diào)用比較迅速,并不是什么問題。但您或許會理解,如果您想通過代理服務(wù)器調(diào)用 MapPoint .NET Web 服務(wù),所使用的連接具有一定的延遲,同時相應(yīng)的服務(wù)可能又要花費一些時間來處理請求,則您可能在各處位置都看到延遲的情況,并且如果站點很忙,便可能出現(xiàn)問題。
改善問題
該問題的某些方面可以通過對環(huán)境進(jìn)行某些配置設(shè)置來改善。我們看一下可用于改善該問題的某些配置設(shè)置。
maxconnections
連接到 Web 資源的默認(rèn)雙連接限制可以通過一個名為 connectionManagement 的配置元素來控制。connectionManagement 設(shè)置允許您添加要讓其采用非默認(rèn)連接限制的站點的名稱。可以將以下內(nèi)容添加到典型的 Web.config 文件中,將您連接的所有服務(wù)器的連接限制默認(rèn)值增加到 40。
<configuration>
<system.net>
<connectionManagement>
<add address="*" maxconnection="40" />
</connectionManagement>
</system.net>
<system.web>
...
應(yīng)當(dāng)注意的是,對本地計算機(jī)的連接數(shù)量從來都沒有限制,因此,如果是連接到本地主機(jī),則此設(shè)置無效。
maxWorkerThreads 和 minFreeThreads
如果收到 HTTP 503 錯誤(“服務(wù)暫時過載”),則表明線程池中的線程已全部占用,并且請求隊列也已超出最大值(appRequestQueueLimit 的默認(rèn)設(shè)置為 100)。對于 IIS 5.0 安裝,可以簡單地增加線程池的大小。而對于 IIS 6.0 安裝(與 IIS 5.0 不兼容),這些設(shè)置將無效。
maxWorkerThreads 和 maxIoThreads 分別控制工作線程數(shù)以及處理新提交的 ASP.NET 請求的線程數(shù)。這些設(shè)置需要在您的 Machine.config 中進(jìn)行配置,它們將影響您計算機(jī)上運(yùn)行的所有 Web 應(yīng)用程序。maxWorkerThreads 是 Machine.config 中的 processModel 元素的一部分,并且您在查看后會發(fā)現(xiàn),該設(shè)置的默認(rèn)值為每個處理器 20 個線程。
minFreeThreads 設(shè)置可以在 Machine.config 中進(jìn)行配置,或者在您的應(yīng)用程序的 Web.config 文件中的 httpRuntime 元素下進(jìn)行配置。該設(shè)置的作用是,當(dāng)空閑的線程數(shù)低于所設(shè)置的限制時,將禁止使用線程池中的線程來處理傳入的 HTTP 請求。如果您需要某個進(jìn)程線程池線程完成掛起的請求,這會很有用。如果所有的線程都被用來處理傳入的 HTTP 請求,并且這些請求在等待另一個線程完成其處理,那么就會進(jìn)入死鎖狀態(tài)。例如,如果您正在從 ASP.NET 應(yīng)用程序進(jìn)行對某個 Web 服務(wù)的異步 Web 服務(wù)調(diào)用,并且在等待回調(diào)函數(shù)完成該請求,就會出現(xiàn)這種情況。因為回調(diào)必須在進(jìn)程線程池中的空閑線程上進(jìn)行。如果查看一下您的 Machine.config,將會注意到 minFreeThreads 設(shè)置的默認(rèn)值為 8,如果工作線程池的限制為 20,則該默認(rèn)值還可以滿足需要,但是,如果線程池的大小增加到 100,該默認(rèn)值就太小了。
應(yīng)當(dāng)注意的是,如果您的 ASP.NET 應(yīng)用程序?qū)Ρ镜赜嬎銠C(jī)進(jìn)行 Web 服務(wù)調(diào)用,則線程池限制的問題將被激化。例如,我為此專欄創(chuàng)建的測試應(yīng)用程序調(diào)用與 ASPX 頁面同處一臺計算機(jī)上的 Web 服務(wù)。因而,對于阻塞的調(diào)用,一個線程被同時用于 ASPX 頁面和 ASMX Web 服務(wù)請求。這有效地使 Web 服務(wù)器處理的同時請求數(shù)增加了一倍。在同時進(jìn)行兩個 Web 服務(wù)請求(使用異步 Web 服務(wù)調(diào)用)的情況下,我們最終使同時進(jìn)行的請求數(shù)增加了兩倍。為避免在回調(diào)本地計算機(jī)時出現(xiàn)此類問題,您應(yīng)當(dāng)考慮您的應(yīng)用程序的體系結(jié)構(gòu),使其簡單地直接從 ASPX 代碼來執(zhí)行 Web&nbs