獲取設備基線性能的想法與實踐
背景
產品的發展離不開功能實現和性能滿足
功能實現還是可以通過功能測試，UAT等方式來驗證。
性能是否滿足有時候比較難處理。
雖然可以通過壓測。但是壓測時總會有太多的變量較難控制
一般客戶也不會提供一套跟生產一樣的環境進行驗證。
感覺此時服務器硬件性能基線的獲取就比較重要了。
通過服務器處理業務需要的資源進行一定比率的縮放。
能夠簡單驗證，產品提供的硬件後是否滿足基本的需求。
需要注意。 驗證服務器資源不夠的話可能比較準確。
但是驗證服務器資源充足卻比較困難。
因爲正常業務的需求可以適量評估。但是異常代碼下的場景無法評估。
很多低效代碼再遇到瓶頸時會出現非常嚴重的性能劣化。
還需要注意點的是：
虛擬機因爲有超獸和漂移的影響， 以及相同宿主機算例爭搶的情況。
所以建議如果對虛擬機進行基線獲取，最好是可以在不同時間節點進行獲取比對。
建議多次進行運算，獲取均值。
物理機器雖然理論上沒有虛擬機的這些異常情況
但是電源供電，空調溫度， 以及網絡擁塞程度偶會影響性能表現
建議也進行明確和確定
基線獲取第一部分-基本硬件信息
0. 機器基本情況：
物理機還是虛擬機， 物理機的話機器配置廠商。
虛擬機的話 虛擬化平臺。存儲使用情況。
1. CPU廠商，型號，主頻，緩存情況。
核心數，主頻。是否超售
2. 內存大小，型號
物理機考慮通道數，DDR幾代，時序，工作頻率2400or3200等
3. 硬盤大小，硬盤類型，硬盤型號
機械硬盤還是固態硬盤，接口類型。快大小。Raid卡類型，Raid卡配置。
4. 操作系統信息
廠商，版本，內核版本，部分內核參數配置，TCP，IO
文件打開數，防火牆，IO調度算法等等。
基線獲取第二部分-測試benchmark
1. CPU算例部分
SPECCPU2006
SPECJVM2008（CPU和內存）
stress-NG
pi計算
context-switch
2. 內存部分
lmbench
cpu-z
3. IO部分
fio、gfio
diskspd
hdtune
dd
4. 網絡部分
netperf
iperf
5. 綜合部分
redis-benchmark
sysbench（數據庫）
性能基線的要求
1. CPU部分
可以使用SPECCPU2006、2017進行驗證。
單核心能力基本上對應RT時間的比例。
多核心能力可以部分反映系統的併發系統性能。
飛騰單核心跑分只有13，導致跟Intel最新CPU比較差距較大。
2. 內存部分
內存部分一般主要是考慮帶寬，時序以及頻率。
基本上CPU都無法餵飽CPU。在CPU能力成瓶頸的情況下
內存越好，性能表現越好。
3. IO部分（磁盤和網絡）
IOPS需要與業務常見的TPS關聯起來，一般數據庫的一個事務的IOPS可能差異巨大。
從1到1000IOPS都有可能， 這一塊要根據業務場景，數據量來分析
需要注意理論上IO僅數據庫部分需要考慮，應用服務器影響啓動和日誌較多，其他影響較小。
網絡部分所有的服務器都需要考慮。
應用服務器既要作爲跟客戶度溝通，又要跟數據庫溝通，其實對帶寬要求很高。
網絡延遲好，帶寬足夠，不丟包纔是良好的性能的前提。
這時候內核參數也很重要
4. 綜合部分
redis-benchmark 很誠實的反饋機器的性能表現。如果有落盤參數，對磁盤也可以進行兼顧測試。
sysbench採用數據庫模式測試，可以反饋部分性能瓶頸，但是意義可能不是非常大。不同業務場景差異巨大。
