最簡單的計算方式就是根據服務器帶寬與頁面的大小css
1.假設機房帶寬爲10Mbs，頁面的大小爲20KB（包含全部的js、css、圖片）數據庫
同時併發量的理論值： 10*1024/(8*20) = 64個請求/秒 服務器
理論上1秒鐘同時能夠有64個請求訪問頁面。併發
注意：10Mbs是位(b)，1個字節8位，因此要除8。優化
2. 假設進來的人是勻速的增長，ui
根據」三秒定律」（頁面打開速度不超過3秒），可得出併發量在單位時間內應是192個請求；spa
一分鐘的請求量在3840。.net
3.根據二八定律，即80%的訪問量發生在20%的時間裏日誌
3840*24*60*0.2/0.8=1382400 人次blog
而發生在天天的高峯期（大約5小時）內的在線人次在110萬人次，一個小時爲22W人次。
4.固然以上的計算都是理論值，如每一個訪問者停留頁面的平均時間爲1分鐘左右，訪問者的進入和退出都是比較符合正態分佈.。
若是是特殊狀況服務器確定是支撐不了這麼多人的，例如同一時間有大批量的訪問者進入，例如考試系統。又或者同時刷新頁面。
並且在實際過程當中，如今的頁面都確定超過20KB，那麼對帶寬的要求也就更大，還有同一個局域網訪問狀況也要考慮。
以筆者的實際項目來講，個人項目是考試系統。出現過2次比較極端的狀況。
本考試系統，登錄的頁面容量比較大，全部的js,css以及圖片未優化前在400KB左右，咱們就以400KB爲基準，全部後面要用的文件是在首頁一次性加載下來的。
我用的是2臺服務器，均爲10Mbs帶寬。 按照上面的計算方式可得出
2臺服務器單位時間內應能夠處理19個請求，一天能承載的測評人次是14W左右，而發生在天天的峯值時間（大約5小時）內在線人次在11W左右。
高峯期一個小時的在線人次在2.2W左右。
第一次咱們測評人數是7949人，而這些測評者主要使用的是本身的手機分散測評，測評的時間線以下
高峯期是在11點期間，而從這一個小時的日誌中查到與實際的服務器數據庫的寫入人次是17783人次（測評系統的特色是除了極少的幾個頁面不參數數據庫數據寫入，其餘都是要寫入答案或者我的信息）。這一天的測評狀況很是順利，服務器沒有任何壓力。
第二次，總共只測了2433人，但其中有1200人左右是在局域網且同時登錄系統，第一次致使其中一臺機器幾乎卡死，後來查看服務器日誌，發現瞬時峯值有150個請求/秒，而且我是將全部的靜態資源如 JS\CSS\圖片都存放在一臺服務器中的，也致使這臺服務器的帶寬一直很高。爲了解決這個問題，只好每隔10秒登錄200個考生，一分鐘內所有登錄完畢，後面1200人同時進行測評沒有任何問題。主要瓶頸就是集中登錄環節。第一次出現問題的時間是下午13點，第二次分批次登錄是17點。測評的時間線以下
而這2個時間段的測評人次分別是和。
能夠看出，出問題的時段，與數據庫交互的次數其實不多，而下午17點有近27000次的交互，由此也能夠得出主要瓶頸就是集中登錄系統致使的，而實際的數據也符合上面的經過計算得出的結果。
本人在csdn的本文連接：http://www.javashuo.com/article/p-omhmcjkx-em.html