普通的Web系統,關於併發量與使用者數的關係計算如下:

1.單臺伺服器最高併發數2000,這是業內的大牛通過各種架構/優化/技術實現的.  我們水平沒那麼高, 但200併發 絕對是沒問題的.

2.單個請求的處理時間, 理論上的極值為70ms(這是內網Web伺服器訪問資料庫伺服器的網路時間),  我們水平沒那麼高, 但也絕對可以在500ms內完成一次請求(不包括使用者到Web伺服器的網路時間)

3.根據以上, 單臺伺服器 每秒可響應 400個請求.

4.每小時響應 144W 請求.

5.每天的響應不能簡單 乘以24, 因為正常系統,晚上沒人用, 電子商務通常在早10,下午14點,晚上19點附近會有高峰期. 根據經驗,高峰期 一小時的請求量是每天請求量的十分之一.

   即每天響應 1440W請求.

6.每個頁面平均有2個請求(Ajax會導致額外的請求), 靜態資源請求不計入,這個只跟網路有關,即,每天響應720W個頁面

7.根據經驗,在網站發生實質性業務的使用者 ,平均開啟100個頁面(這個是往高了說的).  即 單臺伺服器 每天可支援 7.2W個實質交易.

8.根據經驗 每天 登入使用者數是交易使用者數的十倍,但頁面開啟數極少,通常是1-10,  這個忽略.  即, 單臺伺服器每天 有 72W個登入使用者.

9.根據經驗,註冊使用者是每天登入使用者的10倍(如果沒有刷殭屍使用者的話), 單臺伺服器可以為 720W個註冊使用者服務.

10.使用負載均衡後,通常負載均衡伺服器 會是 2/4/8/16 這個規模 , 通常不會超過16.  即 16個負載均衡伺服器 可 服務 1.15億使用者(這個至少也是京東的級別了)

最後: 如果使用者數超過以上計算,或者業務複雜度導致無法實現200併發(如:複雜業務,幾十個流程),那麼 我們會根據實際專案情況 採取 其他技術手段來提高 伺服器叢集的響應能力

如: 快取memcache, 更高速的資料庫mongo/redis,動靜分離CDN,資料庫分庫/分表

再比如: 部分關鍵節點採用Java進行處理, 這裡並不是說Java就比PHP好, 但在極限速度響應上,Java的確比PHP快, Java程序駐留記憶體啊~~~