服務(wù)器網(wǎng)站IIS出現(xiàn)-Server is too busy _解決方法

2.0版本：
原來默認(rèn)的是

改為

不用重新啟動服務(wù)器就可以看到效果。

以上只是個(gè)人實(shí)踐體會，我的服務(wù)器狀態(tài)是：２００３操作系統(tǒng)，

*****************************************************************************************************************************

最近公司的一個(gè)ASP.NET站點(diǎn)頻繁出現(xiàn)Server Too Busy錯(cuò)誤，具體表現(xiàn)為頁面響應(yīng)慢、經(jīng)常出現(xiàn)Server Too Busy異常；但實(shí)際上服務(wù)器的資源消耗卻很低，CPU使用只有10%左右，非常奇怪。

該站點(diǎn)運(yùn)行環(huán)境為Windows 2000，IIS5.0，.NET Framework 1.1，站點(diǎn)壓力約為每秒10個(gè)連接，峰值時(shí)約為30。

從網(wǎng)上查找相關(guān)資料后，從表現(xiàn)出的情況來看（響應(yīng)慢，拋出Server Too Busy異常），初步判斷為同時(shí)連接過多引起的線程阻塞引起。修改web.config中的httpRuntime配置節(jié)中的appRequestQueueLimit參數(shù)后，Server Too Busy 的錯(cuò)誤得到解決。此參數(shù)默認(rèn)從machine.config中繼承，默認(rèn)值為100，改為1000后Server Too Busy的錯(cuò)誤不再出現(xiàn)。

雖然服務(wù)器忙的錯(cuò)誤解決了，但是站點(diǎn)響應(yīng)還是很慢，有時(shí)候要等上5—10秒才能打開頁面。分析原因應(yīng)該是同時(shí)請求過多，而IIS工作線程不足的原因引起，修改machine.config中processModel配置節(jié)maxWorkerThreads參數(shù)為200后站點(diǎn)響應(yīng)速度慢的問題得到解決。此參數(shù)默認(rèn)值為20，可根據(jù)服務(wù)器硬件配置于壓力大小適當(dāng)調(diào)整。

分析原因，是因?yàn)檎军c(diǎn)程序中使用了HttpWebRequest請求外部服務(wù)器的頁面，而這個(gè)操作是相當(dāng)耗時(shí)的（外部服務(wù)器響應(yīng)慢是主要原因）。當(dāng)訪問者的請求到達(dá)ASP.NET工作進(jìn)程后，ASP.NET首先會檢查是否有空余的工作線程（WorkerThread），如果有的話，就交給一個(gè)空閑的工作線程去處理，如果沒有空閑的工作線程，那么這個(gè)請求就會被放到請求隊(duì)列（RequestQueue）中，這個(gè)時(shí)候的表現(xiàn)就是響應(yīng)很慢。當(dāng)訪問量過大導(dǎo)致請求隊(duì)列也滿了的時(shí)候，ASP.NET就會拋出Server Too Busy異常了。在.NET 1.1中，默認(rèn)的工作線程和請求隊(duì)列分別為20和100，當(dāng)運(yùn)行的代碼比較費(fèi)時(shí)而訪問量又較大的時(shí)候，這兩個(gè)默認(rèn)值顯然就太小了。（現(xiàn)在的服務(wù)器硬件便宜了，一般PC服務(wù)器的吞吐量都應(yīng)該遠(yuǎn)超過這個(gè)數(shù)）。這兩個(gè)值可以根據(jù)服務(wù)器壓力大小來進(jìn)行合理配置。以調(diào)整站點(diǎn)吞吐量。
---------------------------------------------------------------------------------
一般來說，當(dāng)您的IIS發(fā)生了諸如"HTTP:1001 Server is too busy"
的錯(cuò)誤時(shí)，是因?yàn)槟腁SP程式中開了過多的Server.CreateObject請求
，然后每一個(gè)請求都需要排隊(duì)等待直到他們確實(shí)被建立了為止。
假如您的隊(duì)列的最大長度為500的話，當(dāng)隊(duì)列中已存在了499個(gè)請求時(shí)，
這時(shí)假如第500個(gè)請求到達(dá)了，就會發(fā)生“Server is too busy”錯(cuò)誤。
那么怎么來使正在申請的請求最小化了，并且怎樣提高響應(yīng)時(shí)間呢，
下面是幾個(gè)建議：
1.盡量使用.HTM后綴的文檔，避免使用.ASP（尤其是在那些有可能招成
超負(fù)荷的條件的特別事件時(shí)）。因?yàn)镠TM不會障塞服務(wù)器同時(shí)能夠得到最大的
緩存性能。（有關(guān)這個(gè)的效率問題我曾介紹過一篇文章，在精華區(qū)中）
2.盡量在您的ASP中少使用Server.CreateObject
3.嚴(yán)格限制您的ASP調(diào)用不在您服務(wù)器上的外部資源，例如您的資源在另外一臺服務(wù)器上
4.盡量優(yōu)化您的網(wǎng)絡(luò)性能和穩(wěn)定性，例如增強(qiáng)您的后臺的SQL Server數(shù)據(jù)庫或則遠(yuǎn)程文檔共享
的局域網(wǎng)性能。
5.盡量讓每一個(gè)組件的執(zhí)行速度快和調(diào)用他的速度.例如，一個(gè)組件一秒鐘被調(diào)用了20次，
那么他就必須在1/20秒的時(shí)間內(nèi)執(zhí)行完成，否則該組件將會阻塞。要知道，一個(gè)阻塞的
組件將會導(dǎo)致您網(wǎng)站上任何的ASP崩潰
6.每個(gè)禮拜都要監(jiān)控您的網(wǎng)站的性能狀態(tài).因?yàn)閱蝹€(gè)能夠產(chǎn)生阻塞的對象能夠?qū)δ恼麄€(gè)網(wǎng)站產(chǎn)生
很不好的影響。

問題未解決？付費(fèi)解決問題加Q或微信 2589053300 (即Q號又微信號)右上方掃一掃可加博主微信

所寫所說，是心之所感，思之所悟，行之所得；文當(dāng)無敷衍，落筆求簡潔。 以所舍，求所獲；有所依，方所成！