最簡單的計算方式就是根據伺服器頻寬與頁面的大小
1.假設機房頻寬為10mbs，頁面的大小為20kb（包含所有的js、css、）
同時併發量的理論值： 10*1024/(8*20) = 64個請求/秒
理論上1秒鐘同時可以有64個請求訪問頁面。
注意：10mbs是位(b)，1個位元組8位，所以要除8。
2. 假設進來的人是勻速的增加，
根據」三秒定律」（頁面開啟速度3秒），可得出併發量在單位時間內應是192個請求；
一分鐘的請求量在3840。
3.根據二八定律，即80%的訪問量發生在20%的時間裡
3840*24*60*0.2/0.8=1382400 人次
4.當然以上的計算都是理論值，如每個訪問者停留頁面的平均時間為1分鐘左右，訪問者的進入和退出都是比較符合正態分佈.。
如果是特殊情況伺服器肯定是支撐不了這麼多人的，例如同一時間有大批量的訪問者進入，例如考試系統。又或者同時重新整理頁面。
而且在實際過程中，現在的頁面都肯定超過20kb，那麼對頻寬的要求也就更大，還有同乙個區域網訪問情況也要考慮。
以筆者的實際專案來說，我的專案是考試系統。出現過2次比較極端的情況。
本考試系統，登陸的頁面容量比較大，所有的js,css以及未優化前在400kb左右，我們就以400kb為基準，所有後面要用的檔案是在首頁一次性載入下來的。
我用的是2臺伺服器，均為10mbs頻寬。 按照上面的計算方式可得出
第一次我們測評人數是7949人，而這些測評者主要使用的是自己的手機分散測評，測評的時間線如下
高峰期是在11點期間，而從這乙個小時的日誌中查到與實際的伺服器資料庫的寫入人次是17783人次（測評系統的特點是除了極少的幾個頁面不引數資料庫資料寫入，其他都是要寫入答案或者個人資訊）。這一天的測評情況非常順利，伺服器沒有任何壓力。
第二次，總共只測了2433人，但其中有1200人左右是在區域網且同時登陸系統，第一次導致其中一台機器幾乎卡死，後來檢視伺服器日誌，發現瞬時峰值有150個請求/秒，並且我是將所有的靜態資源如 js\css\都存放在一台伺服器中的，也導致這台伺服器的頻寬一直很高。為了解決這個問題，只好每隔10秒登陸200個考生，一分鐘內全部登陸完畢，後面1200人同時進行測評沒有任何問題。主要瓶頸就是集中登陸環節。第一次出現問題的時間是下午13點，第二次分批次登陸是17點。測評的時間線如下
而這2個時間段的測評人次分別是
可以看出，出問題的時段，與資料庫互動的次數其實很少，而下午17點有近27000次的互動，由此也可以得出主要瓶頸就是集中登陸系統導致的，而實際的資料也符合上面的通過計算得出的結果。
高併發計算伺服器數量
每秒查詢率qps 對乙個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準，即每秒請求數，即最大談吐能力。併發數 併發數和qps是不同的概念，一般說qps會說多少併發使用者下qps，當qps相同時，併發使用者數越大，併發處理能力越好。當併發使用者數過大時，會造成程序 執行緒 頻繁切換，反正真正用於...
併發伺服器
併發伺服器 伺服器使用多個控制線程，同時處理多個客戶請求。有關併發執行的細節取決於所用作業系統。但其思路很簡單 併發伺服器程式被分為主程式 執行緒 和控制代碼兩部分，主程式只接受來自客戶的連線請求，並為該客戶建立乙個控制線程 每乙個控制線程只與乙個客戶互動，並執行控制代碼程式。當處理完乙個客戶後，該...
併發伺服器
1.select優點 跨平台缺點 對於單個程序的檔案描述符的數量存在最大限制linux一般為1024，32位機器位1024，64位機器位2048 2 對socket進行掃瞄時是一次掃瞄的，即採用輪詢的方法，效率較低 3.遍歷列表浪費cpu時間 poll優點 解決了套接字的上限問題 缺點 效率跟sel...