最簡單的計算方式就是根據服務器帶寬與頁面的大小
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 人次
而發生在每天的高峰期（大約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的本文鏈接：https://blog.csdn.net/zhuiyue82/article/details/85340982