關于并發你真的了解嗎？（一）

本文僅代表帶個人觀點及了解，本人隻是一個程式設計小菜鳥，如果有不對的地方。請大佬輕噴！

    前言：對于很多工作時間短或者程式設計經驗不足的程式員來說，大多數會覺得并發這個詞離自己太遙遠，之是以知道并發也不過是因為受那些技術大佬成天讨論并發等問題耳濡目染罷了。更有甚者，一些所謂的“項目經理”。一邊侃侃而談“大資料”，“高并發處理”等等進階問題，一邊理所當然的寫出Select * 或者是毫無規範性的性能極差的代碼。當然這也跟國内的大環境有一定的關系，導緻很多程式員僅僅隻想滿足功能完成任務即可。實際上并發的處理是和我們日常工作息息相關的無論初級，中級，進階程式員。本文将從整體架構和日常工作，兩個角度來分别講解關于并發的兩三事。隻想了解日常工作中如何規範化的童鞋下拉到自己關心的部分檢視閱讀。

  說道并發，首先你需要了解幾個詞語：

 IIS連接配接數、IIS并發連接配接數、IIS最大并發工作線程數、應用程式池的隊列長度、最大工作程序數調試

IIS連接配接數

一般購買過虛拟主機的朋友都熟悉購買時，會限制IIS連接配接數，這邊先從普通不懂代碼使用者角度了解IIS連接配接數

顧名思義即為IIS伺服器可以同時容納客戶請求的最高連接配接數，準确的說應該叫“IIS限制連接配接數”

這邊客戶請求的連接配接内容包括：

1、網站html請求，html中的圖檔資源，html中的腳本資源，其他需要連接配接下載下傳的資源等等,任何一個資源的請求即一次連接配接（雖然有的資源請求連接配接響應很快）

2、如果網頁采用架構（架構内部嵌套網頁請求），那麼一個架構即一次連接配接

3、如果網頁彈出視窗（視窗内部嵌套網頁請求），那麼一個視窗一個連接配接

限制連接配接數即為虛拟主機供應公開的IIS連接配接數标準，如果購買的IIS連接配接數為50,那麼我們不得不考慮網站的内容架構和通路量

如果網站圖檔夠多，彈窗視窗随意（可能連時間選擇框、簡單條件篩選框也用彈出新視窗），加上不得已的打開新頁面浏覽内容，那麼僅僅能容忍10個人同時操作也很正常，我不會把這個操作描述為很多網站說的“10同時線上”，這很容易讓人誤解，在使用者的一次請求（表面上可能是重新整理一次網頁，實際上内部請求不止一次，事實上很少隻有一次）都完成得到伺服器響應完畢之後，連接配接全部會被釋放，當然在你看到展示的頁面之前，内部嵌套如果有請求圖檔等連接配接請求，連接配接會早早的被釋放

事實上，很多企業門戶網站通路量低的驚人，IIS連接配接數為50也是綽綽有餘了

IIS并發連接配接數

其實，普通使用者常說的“IIS連結數”就是這邊的“最大并發連接配接數” ，我這邊IIS預設最大并發連接配接數為：4294967295，這是一個很驚人的數字，難道這代表着網站能具有并發執行連接配接數為4294967295的能力？

這邊我做幾個假設：

1、很多虛拟主機供應商所說的無并發連接配接數限制真的成立嗎？

2、每個連接配接的處理，IIS都會開啟一個線程去處理，假設這個處理方式成立，那麼4294967295個并發連接配接請求來了是否IIS會立即啟動4294967295個線程去處理？

對于1：很顯然不成立，最大并發連接配接數的設定絕對有上限

對于2： 這是很多朋友的誤區，假設4294967295并發連接配接同時來了，IIS不會立即啟動4294967295個線程去處理，因為這不現實，對于處理連接配接，IIS是有“ 最大并發工作線程數 ”限制的，這是我下面要介紹的，我從一些資料上查閱到， 該數字跟作業系統 相關，win7 系統的IIS的值是10（或者其他不确定），VS2012自帶的IIS Express的值是80。對于w indows 伺服器版本的系統 的具體值不清楚，即4294967295個并發連接配接來了後，（這邊以win7下的10為例），iis第一時間隻能啟動10個工作線程去處理，那麼其他42949672 85 必須排隊，排隊對使用者的體驗來說就是網頁正在加載，但是什麼都不顯示，然後此時購買了據虛拟主機供應商所說的無并發連接配接數限制的客戶就要開始狂暴了，為何購買了所謂的“無限并發連接配接數”，還是會一直在加載的情況，我隻能說這就是IIS處理能力有限的問題了

當然伺服器沒有直接傳回“ HTTP Error 503. The service is unavailable.”應該也算是一些你花更多錢的安慰吧，因為你隻購買了IIS連接配接數為50的話，那麼第50+1個連接配接請求操作得到的就直接是“HTTP Error 503. The service is unavailable.”了

另外，如果web伺服器的硬體裝置夠爽朗（牛逼），那麼IIS的工作線程也會處理的更快，那麼響應的使用者等待的時間也會更短（前提是你的IIS連接配接數夠大哦，否則就直接503了哦）

總的來說，最大并發連接配接數，影響了排隊的數量，

很多時候需要我們評估自己的網站的最大并發連接配接數，然後來進行設定最佳數量

IIS最大并發工作線程數

這個在上面有所涉及，簡單的說就是IIS在并發連接配接請求過來時的處理機制，它會更機智的以某個數量級為機關來分批處理，讓沒有處理連接配接請求排隊等待，使用者浏覽器中對于排隊等待的響應就是“正在加載”，這比頁面直接顯示“ HTTP Error 503. The service is unavailable. ”更加能讓人接受，但是切勿氣急敗壞的怒點重新整理按鈕，因為點的越多，你的請求在排隊隊伍中越靠後。

當然很多朋友會說，為什麼我有時候第一次刷不出來，重新多刷一次内容就出來了？ 

1、頁面腳本哪個地方下載下傳或者處理出了問題，導緻頁面顯示異常或者直接不顯示

2、你重新重新整理的那個秒級别的操作，web伺服器更快速的已經處理好了其他隊列的請求或者他人放棄了對web伺服器連接配接請求的操作

3、路由或者寬帶網絡營運商問題（不穩定）

4、浏覽器或者本身電腦問題

那麼現在問題來了，最大并發連接配接數，影響了排隊的數量，那麼有沒有進步影響排隊數量的設定? 有的：隊列長度

隊列長度

假設最大連接配接數設定為100，1000個并發連接配接請求過來了，首先900直接傳回給客戶“HTTP Error 503. The service is unavailable.”

然後IIS先啟動（假設最大并發工作線程數為10）10個線程處理請求，其他90個進入排隊狀态，如果此時如下操作：

找到網站的所屬應用程式池，“右擊進階設定”->"正常"->"列隊長度"，設定為20

那麼實際情況又會變成什麼樣子呢？隻會有20個進入排隊狀态了，70（90-20）個請求也會立刻傳回“HTTP Error 503. The service is unavailable”

iis預設隊列長度設定是1000，範圍在10-65535 之間

最大工作程序數

應用程式池一般預設最大工作程序數為1，可以找到網站的所屬應用程式池，“右擊進階設定”->"程序模型"->"最大工作程序數" 來修改設定

如果這個值大于 1，那麼當有連接配接請求時會啟動多個新的工作程序執行個體，可啟動的最多程序數為您所指定的最大工作程序數，後續更多的請求将以循環的方式發送至工作程序，這個每個工作程序都能承擔負載一些連接配接請求，當然是以消耗cpu等硬體做代價，這是值得的，如果web伺服器cpu使用率很低但是又需要更高效的處理并發連接配接請求，為何不這麼做呢？

如果網站中用到了依賴程序的Session和Cache等對象，則不能儲存在伺服器記憶體中，存儲方式選用StateServer或者SQLServer會更好，另外多個工作程序切換時會有上下文複制，這也是資源消耗更多地方

最大工作程序數調試

最大工作程序數的設定方法：（拷貝）按照每工作程序能承載30個并發的原則來确定應用程式池的最大工作程序數。同時要注意，每個工作程序大約會占用200M左右的系統記憶體，在設定最大工作程序數的時候，要主要最大工作程序數與200M的乘積不要超過系統最大可用記憶體數。一般情況下，建議按照每次增加5個工作程序數的方式對最大工作程序數進行調整，調整完後對網站觀察一段時間，如依然無法滿足要求，再繼續增加5個工作程序數。

本文版權歸作者 心灬無痕（博文位址：http://www.cnblogs.com/xinwuhen/）所有，歡迎轉載和商用，請在文章頁面明顯位置給出原文連結并保留此段聲明，否則保留追究法律責任的權利，其他事項，可留言咨詢。