常用性能數字（一）
前言
存儲硬件
CPU 和內存硬件
操作系統和應用程序相關
幾個重要概念和指標
Linux 平均負載
前言
存儲硬件
CPU 和內存硬件
操作系統和應用程序相關
幾個重要概念和指標
Linux 平均負載
網絡相關
中間件相關
網站規模
服務器規模
總結
前言
對于性能工程師來說，常見系統的性能數據量級需要爛熟于心，記住這些數字的好處是，每次看到一個性能相關的數據的時候，我們立刻就能知道這個性能數據有沒有問題。
舉個簡單例子，如果我們看到一個硬盤的 IO 讀寫延遲經常在 500 毫秒左右，我們立刻就知道這里面有性能問題。反之，如果硬盤 IO 讀寫延遲小于 1 毫秒，我們可以馬上推斷——這些 IO 讀寫并沒有到達硬盤那里，是被操作系統緩存擋住了。這就是大家常說的“對數字有感覺”。
存儲硬件
存儲有很多種，常用的是傳統硬盤（HDD,）和固態硬盤（SSD），SSD 的種類很多，按照技術來說有單層（SLC）和多層（MLC，TLC 等）。按照質量和性能來分，有企業級和普通級。根據安裝的接口和協議來分，有 SAS、SATA、PCIe 和 NVMe 等。
對所有的存儲來說，有三個基本的性能指標。
IO 讀寫延遲。一般是用 4KB 大小的 IO 做基準來測試；
IO 帶寬，一般是針對比較大的 IO 而言；
IOPS，就是每秒鐘可以讀寫多少個小的隨機 IO。
SSD 的隨機 IO 延遲比傳統硬盤快百倍以上，IO 帶寬也高很多倍，隨機 IOPS 更是快了上千倍。
CPU 和內存硬件
幾個基本的指標：
CPU 的時鐘頻率，也就是主頻。主頻反映了 CPU 工作節拍，也就直接決定了 CPU 周期大小。
CPI 和 IPC：CPI衡量平均每條指令的平均時鐘周期個數。它的反面是 IPC。雖然一個指令的執行過程需要多個周期，但 IPC 是可以大于 1 的，因為現代 CPU 都采用流水線結構。一般來講，測量應用程序運行時的 IPC，如果低于 1，這個運行的系統性能就不是太好，需要做些優化來提高 IPC。
MIPS：每秒執行的百萬指令數。我們經常會需要比較不同 CPU 硬件的性能，MIPS 就是一個很好的指標，一般來講，MIPS 越高，CPU 性能越高。MIPS 可以通過主頻和 IPC 相乘得到，也就是說 MIPS= 主頻×IPC。
CPU 緩存：一般 CPU 都有幾級緩存，分別稱為 L1、L2、L3。L3 是最后一級緩存。
值得一提的是現在的 NUMA 處理器會有本地和遠端內存的區別，當訪問本地節點的內存是會快一些。
操作系統和應用程序相關
我們剛剛談了硬件方面，下面看看軟件，也就是操作系統和應用程序。
幾個重要概念和指標
指令分支延遲：CPU 需要先獲取指令，然后才能執行。獲取下一條指令時需要知道指令地址，如果這個地址需要根據現有的指令計算結果才能決定，那么就構成了指令分支。CPU 通常會采取提前提取指令這項優化來提高性能，但是如果是指令分支，那么就可能預測錯誤，預先提取的指令分支并沒有被執行。
互斥加鎖和解鎖：互斥鎖（也叫 Lock）是在多線程中用來同步的，可以保證沒有兩個線程同時運行在受保護的關鍵區域。
上下文切換：多個進程或線程共享 CPU 的時候，就需要經常做上下文切換。這種切換在 CPU 時間和緩存上都很大代價；尤其是進程切換。
Linux 平均負載
系統過載并超過1.0的負載值有時不是問題，因為即使有一些延遲，CPU也會處理隊列中的作業，負載將再次降低到1.0以下的值。但是如果系統的持續負載值大于1，則意味著它無法吸收執行中的所有負載，因此其響應時間將增加，系統將變得緩慢且無響應。高于1的高值，尤其是最后5分鐘和15分鐘的負載平均值是一個明顯的癥狀，要么我們需要改進計算機的硬件，通過限制用戶可以對系統的使用來節省更少的資源，或者除以多個相似節點之間的負載。
因此，我們提出以下建議：
>=0.70：沒有任何反應，但有必要監控 CPU 負載。如果在一段時間內保持這種狀態，就必須在事情變得更糟之前進行調查。
>=1.00：存在問題，您必須找到并修復它，否則系統負載的主要高峰將導致您的應用程序變慢或無響應。
>=3.00：你的系統變得 非常慢。甚至很難從命令行操作它來試圖找出問題的原因，因此修復問題需要的時間比我們之前采取的行動要長。你冒的風險是系統會更飽和并且肯定會崩潰。
>=5.00：你可能無法恢復系統。你可以等待奇跡自發降低負載，或者如果你知道發生了什么并且可以負擔得起，你可以在控制臺中啟動 kill -9
網絡相關
網絡的傳輸延遲是和地理距離相關的。網絡信號傳遞速度不可能超過光速，一般光纖中速度是每毫秒 200 公里左右。如果考慮往返時間（RTT），那么可以大致說每 100 公里就需要一毫秒。
在機房里面，一般的傳輸 RTT 不超過半毫秒。如果是同一個機柜里面的兩臺主機之間，那么延遲就更小了，小于 0.1 毫秒。
另外要注意的是，傳輸延遲也取決于傳輸數據的大小，因為各種網絡協議都是按照數據包來傳輸的，包的大小會有影響。比如一個 20KB 大小的數據，用 1Gbps 的網絡傳輸，僅僅網卡發送延遲就是 0.2 毫秒。
中間件相關
先說說負載均衡，硬負載性能遠遠高于軟負載。Ngxin 的性能是萬級；LVS 的性能是十萬級，據說可達到 80 萬 / 秒；而 F5 性能是百萬級，從 200 萬 / 秒到 800 萬 / 秒都有（數據來源網絡，僅供參考，如需采用請根據實際業務場景進行性能測試）。當然，軟件負載均衡的最大優勢是便宜，一臺普通的 Linux 服務器批發價大概就是 1 萬元左右，相比 F5 的價格，那就是自行車和寶馬的區別了。
具體的數值和機器配置以及測試案例有關，但大概的量級不會變化很大。
如果是業務系統，由于業務復雜度差異很大，有的每秒 500 請求可能就是高性能了，因此需要針對業務進行性能測試，確立性能基線，方便后續測試做比較。
網站規模
這里就大致根據理論最大TPS，給網站做幾個分類：
小網站：沒什么好說的，簡單的小網站而已，你可以用最簡單的方法快速搭建，短期沒有太多的技術瓶頸，只要服務器不要太爛就好。
DB極限型：大部分的關系型數據庫的每次請求大多都能控制在 10ms 左右，即便你的網站每頁面只有一次DB請求，那么頁面請求無法保證在1秒鐘內完成100個請求，這個階段要考慮做 Cache 或者多 DB負 載。無論那種方案，網站重構是不可避免的。
帶寬極限型：目前服務器大多用了 IDC 提供的“百兆帶寬”，這意味著網站出口的實際帶寬是 8M Byte 左右。假定每個頁面只有 10K Byte，在這個并發條件下，百兆帶寬已經吃完。首要考慮是 CDN加速／異地緩存，多機負載等技術。
內網帶寬極限＋cache極限型：由于 Key/value 的特性，每個頁面對 cache 的請求遠大于直接對DB的請求，cache 的悲觀并發數在 2w 左右，看似很高，但事實上大多數情況下，首先是有可能在次之前內網的帶寬就已經吃光，接著是在 8K QPS左右的情況下，cache已經表現出了不穩定，如果代碼上沒有足夠的優化，可能直接將壓力穿透到了DB層上，這就最終導致整個系統在達到某個閥值之上，性能迅速下滑。
FORK/SELECT，鎖模式極限型：一句話：線程模型決定吞吐量。不管你系統中最常見的鎖是什么鎖，這個級別下，文件系統訪問鎖都成為了災難。這就要求系統中不能存在中央節點，所有的數據都必須分布存儲，數據需要分布處理。總之，關鍵詞：分布
C10K極限：盡管現在很多應用已經實現了 C25K，但短板理論告訴我們，決定網站整體并發的永遠是最低效的那個環節。
服務器規模
我們可以來算一下，根據行業內的經驗，可以估計如下的投入：
可以看到，十萬用戶到上億用戶，也就多了 100 倍，為什么服務器需要 1000 倍？這完全不是呈線性的關系。
這時因為，當架構變復雜了后，你就要做很多非功能的東西了，比如，緩存、隊列、服務發現、網關、自動化運維、監控等。
總結
今天分享了幾組性能數字，希望起到拋磚引玉的效果。你可以在此基礎上，在廣度和深度上繼續擴展。
參考資料：
[1]：《左耳聽風》
[2]：《從0開始學架構》
[3]：《性能工程高手課》
網站 網絡
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
