qps = req/sec = 請求數/秒
qps: 每秒鐘
處理完請求的次數；注意這裡是
處理完。具體是指發出請求到伺服器處理完成功返回結果。可以理解在server中有個counter，每處理乙個請求加1，1秒後counter=qps。
【qps計算pv和機器的方式】
qps統計方式 [一般使用 http_load 進行統計]
qps = 總請求數 / ( 程序總數 * 請求時間 )
qps: 單個程序每秒請求伺服器的成功次數
單台伺服器每天pv計算
公式1：每天總pv = qps * 3600 * 6
公式2：每天總pv = qps * 3600 * 8
伺服器計算
伺服器數量 = ceil( 每天總pv / 單台伺服器每天總pv )
【峰值qps和機器計算公式】
原理：每天80%的訪問集中在20%的時間裡，這20%時間叫做峰值時間
公式：( 總pv數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(qps)
機器：峰值時間每秒qps / 單台機器的qps = 需要的機器
問：每天300w pv 的在單台機器上，這台機器需要多少qps？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (qps)
問：如果一台機器的qps是58，需要幾台機器來支援？
答：139 / 58 = 3
tps：每秒鐘處理完的事務次數，一般tps是對整個系統來講的。乙個應用系統1s能完成多少事務處理，乙個事務在分布式處理中，可能會對應多個請求，對於衡量單個介面服務的處理能力，用qps比較多。
評價乙個**的「大小」，處於視角的不同，有很多種衡量的方法，類似文章數，頁面數之類的資料非常明顯，也沒有什麼可以爭議的。但對於併發來說，爭議非常之多，這裡就從乙個技術的角度開始，談談幾個web**的數量級。
這裡就大致根據理論最大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以上的**，希望有此經驗的哥們可以一起交流下
簡述高併發
一 什麼是高併發 高併發 high concurrency 是網際網路分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。高併發相關常用的一些指標有響應時間 response time 吞吐量 throughput 每秒查詢率qps query per se...
到底什麼級別才算是高併發？
寫這個話題是因為我對搜尋引擎給我的答案很不滿意，然後決定把思考的一些東西分享出來，希望可以大家彼此討論下。我們經常在面試的時候，被問到有沒有高併發的經驗？先不說哪些考高併發的裝逼公司。我思考的是什麼才算是高併發？你一天幾個pv肯定高不了。首先在網上查詢一下，並未找到明確的標準定義。那麼什麼是併發呢？...
併發容器簡述
在前不久的開發工作中接觸到了併發容器中的cow併發容器，所以這裡就併發容器做乙個簡單的總結。首先，併發容器按實現原理分為以下幾種 1.copy on write，比如 copyonwritearraylist，copyonwritearrayset 在需要往集合中新增元素時，首先複製乙個新的集合物件...