Web網站的幾個併發量級

評價一個網站的「大小」，處於視角的不一樣，有不少種衡量的方法，相似文章數，頁面數之類的數據很是明顯，也沒有什麼能夠爭議的。但對於併發來講，爭議很是之多，這裏就從一個技術的角度開始，談談幾個Web網站的數量級。

相信不少人談論一個網站的熱度，總免不了會詢問日均PV，同時在線人數、註冊用戶數等運營數據，說實話從技術角度來講，這幾個數值沒有一個能夠放在一塊兒比較的——一個靜態網站的PV跟一個SNS類/Web Game網站的PV根本就不是一回事。因爲互聯網有一個傳說中的「3秒定律」，可能當下更多的網站技術指標要求1.5秒之內加載整頁，或者至少能夠達到閱讀的標準。若是要較真什麼「同時在線」，絕不客氣的說，對於HTTP這類短連接的網絡協議來講，在WebSocket還不普及的時代，能統計在線純屬扯淡，惟一能作的只是取個時間段，計算下訪問用戶而已。這些依然能夠換算成QPS（Quest Per Second每秒請求數）。就併發而言，我惟一推崇的只有理論最大QPS和悲觀QPS。

 

這裏就大體根據理論最大QPS，給網站作幾個分類

50QPS如下——小網站

沒什麼好說的，簡單的小網站而已，就如同本站這樣，你能夠用最簡單的方法快速搭建，短時間沒有太多的技術瓶頸，只要服務器不要太爛就好。

50～100QPS——DB極限型

大部分的關係型數據庫的每次請求大多都能控制在0.01秒左右，即使你的網站每頁面只有一次DB請求，那麼頁面請求沒法保證在1秒鐘內完成100個請求，這個階段要考慮作Cache或者多DB負載。不管那種方案，網站重構是不可避免的。

300～800QPS——帶寬極限型

目前服務器大多用了IDC提供的「百兆帶寬」，這意味着網站出口的實際帶寬是8M Byte左右。假定每一個頁面只有10K Byte，在這個併發條件下，百兆帶寬已經吃完。首要考慮是CDN加速／異地緩存，多機負載等技術。

500～1000QPS——內網帶寬極限＋Memcache極限型

因爲Key/value的特性，每一個頁面對memcache的請求遠大於直接對DB的請求，Memcache的悲觀併發數在2w左右，看似很高，但事實上大多數狀況下，首先是有可能在次以前內網的帶寬就已經吃光，接着是在8K QPS左右的狀況下，Memcache已經表現出了不穩定，若是代碼上沒有足夠的優化，可能直接將壓力轉嫁到了DB層上，這就最終致使整個系統在達到某個閥值之上，性能迅速下滑。

1000～2000QPS——FORK/SELECT，鎖模式極限型

好吧，一句話：線程模型決定吞吐量。無論你係統中最多見的鎖是什麼鎖，這個級別下，文件系統訪問鎖都成爲了災難。這就要求系統中不能存在中央節點，全部的數據都必須分佈存儲，數據須要分佈處理。總之，關鍵詞：分佈

2000QPS以上——C10K極限

儘管如今不少應用已經實現了C25K，但短板理論告訴咱們，決定網站總體併發的永遠是最低效的那個環節。我認可我生涯中從未遇到過2000QPS以上，甚至1.5K以上的網站，但願有此經驗的哥們能夠一塊兒交流下

 

 

轉：http://www.litrin.net/2013/03/27/web%E7%BD%91%E7%AB%99%E7%9A%84%E5%87%A0%E4%B8%AA%E5%B9%B6%E5%8F%91%E9%87%8F%E7%BA%A7/