2.0版本：
原來默認的是

改為

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

以上只是個人實踐體會，我的服務器狀態是：２００３操作系統，

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

最近公司的一個ASP.NET站點頻繁出現Server Too Busy錯誤，具體表現為頁面響應慢、經常出現Server Too Busy異常；但實際上服務器的資源消耗卻很低，CPU使用只有10%左右，非常奇怪。

該站點運行環境為Windows 2000，IIS5.0，.NET Framework 1.1，站點壓力約為每秒10個連接，峰值時約為30。

從網上查找相關資料后，從表現出的情況來看（響應慢，拋出Server Too Busy異常），初步判斷為同時連接過多引起的線程阻塞引起。修改web.config中的httpRuntime配置節中的appRequestQueueLimit參數后，Server Too Busy 的錯誤得到解決。此參數默認從machine.config中繼承，默認值為100，改為1000后Server Too Busy的錯誤不再出現。

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

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

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

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