1. 程式人生 > >服務器負載粗略估算

服務器負載粗略估算

用戶數 數據庫 details 復雜度 gpo 節點 使用 AI 小時

轉載:https://blog.csdn.net/bluehire/article/details/61922384

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進程駐留內存啊~~~

服務器負載粗略估算