>本章內容摘自《高性能MySQL第三版》第二章節,并不是完全摘抄,按照本人的一些理解進行了刪改,如有不理解地方,請閱讀原文。
### 第1章 為什么需要基準測試
測量系統在給定的工作負載下會發生什么。
觀察系統在不同壓力下的行為,評估系統容量。
觀察系統如何處理不同數據。
驗證基于系統的一些假設,確認這些假設是否會符合實際情況。
重現系統中的某些異常行為,以解決這些異常。
測試系統當前的運行情況。如果不清楚當前系統的性能,就無法確認某些優化的效果如何。
模擬比當前系統更高的負載,以找出系統對著壓力增加而可能遇到的擴展性瓶頸。
規劃未來的業務增長。評估在項目未來的負載下,需要什么樣的硬件,需要多大容量的網絡,幫助降低系統升級和重大變更的風險。
測試應用適應可變環境的能力。可以發現系統在隨機的并發峰值下的性能表現,或者不同配置的服務器之間的性能表現。也可以測量系統對不同數據分布的處理能力。
測試不同硬件、軟件、操作系統配置。比如RAID 還是和RAID10更合適當前系統?從本地磁盤存儲升級到SAN存儲,對于隨機寫性能有什么幫助?Linux 2.4系列內核回避2.6系列的可擴展性更好么?升級軟件版本能改善性能么?
證明新采購的設備是否配置正確。發現服務器硬件的錯誤配置。
### 第2章 測試何種指標
#### 2.1 基準測試的策略
基準測試有兩種主要的策略:一是針對整個系統的整體測試,另外是單獨測試。這兩種策略被稱為集成式(full-stack)和單組件試(single-component)基準測試。
- 針對整個系統做集成式測試,原因主要有以下幾點:
- 測試整個應用系統,包括Web服務器、應用代碼、網絡和數據庫是非常有用的,因為用戶關注的并不僅僅是某個應用本身的性能,而是應用整體的性能。
- 數據庫并非總是應用的瓶頸,通過整體測試可以揭示這一點。
- 只有對應用做整體測試,才能發現各個部分之間的緩存帶來的影響。
- 整體應用的集成式測試更能揭示應用的真實表現,而單獨組件的測試很難做到這一點
有時候不需要了解整個系統的情況,而只需要關注單獨應用的性能,至少項目初期可以這樣做。
#### 2.2 測試何種指標
開始基準測試甚至是設計基準測試之前,需要先明確測試的目標。測試決定選擇什么樣的測試工具和技術,以獲取精確而有意義的測試結果。可以將測試目標細化為一些列問題,比如“增加緩存是否能夠帶來性能提升?”
有時候需要用不同的方法測試不同的指標,比如針對延遲(latency)和吞吐量(throughput)就需要采用不同的測試方法
##### 吞吐量
吞吐量指的是單位時間愛你內的事務處理數量。主要針對在線事務的吞吐量,非常適合多用戶的交互式應用。常用測試單位是每秒事務數(TPS)和每分鐘事務數(TPM)
##### 響應時間或延遲
這個指標用于測試任務所需的整體時間。根據具體應用,測試漸漸單位可能是微秒、毫秒、秒或分鐘。根據不同的時間單位,可以計算出平均響應時間、最小響應時間、最大響應時間和所占百分比。最大響應時間通常意義不大,因為測試時間越長,最大響應時間可能越大。而其結果不可重復,每次測量可能得到不同的最大響應時間。因此,通常可以使用百分比響應時間(percentile response time)來代替最大響應時間。例如,如果95%的響應時間都是5毫秒,則表示人物的95%的時間都可以在5毫秒內完成。
使用圖標有助于理解測試結果。
##### 并發性
并發性是一個非常重要又經常被被誤解和誤用的指標。例如,它經常被表示成多少用戶在同一時間瀏覽一個Web站點,經常使用的指標是有多少個回話。然而,HTTP協議是無狀態的,大多數用戶只是簡單的讀取瀏覽器上顯示的信息,這并不等同于Web服務器的并發性。而且,Web服務器的并發性也不等同于數據庫的并發性,而僅僅只表示回話存儲機制可以處理多少數據的能力。Web服務器的并發性更準確的度量指標,應該任意時間有多少同時發生的并發請求。
在應用的不同緩解,都可以測量響應的并發性。Web服務器的高并發,一般會導致數據庫的高并發,但服務器采用的語言和工具集對此都會有影響。注意不要將創建數據庫鏈接和并發性搞混淆。
一個設計良好的應用,可以同時打開成百上千個數據庫鏈接,但可能只有少數連接在執行。所以說,一個Web站點”同時有50000個用戶“訪問,卻可能只有10~15個并發請求道數據庫。
換句話說,并發性基準測試關注的是正在工作中的并發操作,或者是同時工作中的線程數或者連接數。當并發性增加時,需要測試吞吐量是否下降,響應時間是否邊長,如果是這樣,應用可能就無法處理峰值夜里。
并發性的測試完全不同于響應時間和吞吐量。它不想一個結果,而更像是設置基準測試的一種屬性。并發測試通常不是為了測試應用能達到的并發度,而是為了測試應用在不同并發下的性能。
##### 可擴展性
在系統的業務壓力可能發生變化的情況下,測試可擴展性就非常重要了。簡單的說,可擴展性指的是,給系統增加一倍的工作,在理想情況下,能夠獲得兩倍的結果(即吞吐量增加一倍)。或者說,給系統增加一倍的資源(比如兩倍的CPU),就可以獲得兩倍的吞吐量。當然,同時吸能(響應時間)也必須在可以介紹的范圍內。大多數系統無法做到如此理想的線性擴展。隨著壓力的變化,吞吐量和性能都可能越來越差。
可擴展性指標對于容量規劃非常有用,它可以提供其他基準測試無法系統的信息。比如系統是基于單個用戶的響應時間測試(這是一個很糟糕的測試策略)設計的,雖然測試的結果很好,但并發度增加時,系統的性能有可能變得非常糟糕。而一個不斷增加愛用戶連接的情況下的響應時間測試則可以發現這些問題。
歸根結底,應該測試那些對用戶來說最重要的指標。因此應該盡可能的收集一些需求,比如,什么樣的響應時間是可以介紹的,期待多少并發性,等等。然后基于這些需求來設計基準測試,避免目光短淺的只關注部分指標,忽略其他指標。
### 第3章 基準測試方法
#### 3.1 如何避免一些常見錯誤
- 使用真實數據的自己而不是全集。例如應用需要處理幾百GB的數據,但測試只使用1GB數據;或者只使用當前數據進行測試,卻希望模擬未來業務大幅增長后的情況。
- 使用錯誤的數據分布。例如使用均勻分布的數據測試,而系統的真實數據有很多熱點區域(隨機生成的測試數據通常無法模擬真實的數據分布)。
- 使用不真實的分布參數,假定所有用戶的個人信息都會平均的讀取。
- 在多用戶的場景中,只做單用戶的測試。
- 在單服務器上測試分布式應用。
- 與真實用戶行為不匹配。例如Web頁面中的”思考時間“。真實用戶在請求道一個頁面后,會閱讀一段時間,而不是不停頓的一個接一個點擊相關鏈接。
- 反復執行同一個查詢。真實的查詢時不盡相同的,這可能導致緩存命中率降低。而繁蕪執行同一個查詢,在某種程度上,會全部或者部分緩存結果。
- 沒有檢查錯誤。如果測試的結果無法得到合理的解釋,比如一個本應該是很慢的查詢突然變快了,就應該檢查是否是有錯誤產生。基準測試后,一定要檢查一下錯誤日志,這是基本要求。
- 忽略了系統預熱(warm up)的過程。例如系統重啟后馬上進行測試。有時候需要了解系統重啟后需要多長時間才能達到正常的系統容量,需要特別留意預熱的時間。反過來說,如果想分析正常的性能,需要注意,基準測試在重啟后馬上啟動,則緩存是冷的,沒有數據,這時候即使測試的壓力相同,得到的結果和緩存已經裝滿數據時是不同的。
- 使用默認的服務器配置。
- 測試時間太短。基準測試需要持續一定時間
只有避免了上述錯誤,才能走上改進測試質量的漫漫長路。
如果其他條件相同,就應該努力使測試盡可能的真實應用的情況。當然,有時候和實際情況曬為有些出入問題也不打。例如,實際應用服務器和數據庫服務器分別部署在不同的機器。如果采用和實際部署完全相同的配置當然更真實,但也會引入更多變化,比如網路負載和速度。在單一節點上運行測試相對容易,在某些情況下結果也可以介紹,那么就在單一節點上進行測試。當然,這樣的選擇需要根據實際情況來分析是否合適。
#### 3.2 設計和規劃基準測試
規劃基準測試的第一步是提出問題并明確目標。然后決定是采用標準的基準測試,還是設計專用的測試。
建立測試和結果文檔化的規范,每輪測試都必須進行詳細記錄。文檔規范可以很簡單,可以采用電子表格或記事本,也可以是復雜的自定義數據庫。需要記住的是,經常需要寫一些腳本來分析結果,因此如果能夠不用打開電子表格或者文本等額外操作是最好的。
#### 3.3 獲取系統性能和狀態
執行基準測試時,需要盡可能的多手機測試系統的信息。最好為基準測試建立一個目錄,并且沒執行議論測試,都創建單獨的子目錄,將測試結、配置文件、測量指標、腳本和其他相關說明保存在其中。及時有些結果目前不需要,也應該保存下來。多余一些數據總比缺乏重要的數據搖號,二多余的數據以后或許用得著。需要記錄數據包括系統狀態和性能指標,諸如CPU使用率、磁盤I/O、網絡流量、應用狀態。
#### 3.4 獲得準確的測試結果
獲得準確測試結果的最好辦法,是回答一些基準測試的基本問題
- 是否選擇了正確的基準測試?
- 是否為問題收集了相關主句?
- 是否采用了錯誤的測試標準(比如是否對一個I/O密集型應用,采用了CPU密集型測試標準)
接著,確認測試結果是否可重復性。每次重新測試前,確保系統狀態是一致的。如果是非常重要的測試,需要每次測試都重啟系統。如果測試過程修改數據或者schema,那么每次測試前,需要利用快照還原數據。在表中插入1000條和插入100萬條記錄,測試結果肯定不同。數據碎片度和磁盤上的分布,都可能導致測試時不可重復的。
要注意的因素很多,包括外部的壓力、性能分析和監控系統、詳細的日志記錄、周期性作業。例如,測試過程中突然有cron定時作業啟動,或者RAID卡啟動了定時的一致性檢查。需要確保基準測試過程中所需要的資源是專用于測試的。如果有其他額外的操作,會消耗網絡帶寬,或者測試基于的是其他服務器共享的SAN存儲,那么得到的結果可能是不準確的。
每次測試中,修改的參數應該盡量少。如果必須要一次修改多個參數,那么可能會丟失一些信息。有些參數依賴其他參數,這些參數無法單獨修改。有時候甚至沒有意識到這些依賴,這給測試帶來了復雜性。
#### 3.5 運行基準測試并分析結果
基準測試通常需要運行多次。具體需要運行多少次看對結果的計分方式,以及測試的重要程序。一般取最好值或平均值,亦或5次測試中最好的三個值的平均值。
獲得測試結果后,需要對結果進行分析,也就是把數字變成知識。最終的目的是回答在設計測試是的問題。理想情況下,莪可以一獲得諸如”升級4核CPU可以在保持響應時間不變的情況下,獲得超過50%的吞吐量增加“或者”增加索引可以使查詢更滑“的結論。
#### 3.6 繪圖的重要性
簡單有效的圖形,就是將性能指標按照時間順序繪制。通過圖形可以理解發現一些問題,而這些問題再原始數據中卻很難被注意到。或許你會堅持看測試工具打印出來的平均值或其他匯總過的信息,但平均值有時候是沒有用的,他會掩蓋掉一些實際情況。
### 第4章 基準測試工具
#### 4.1 集成測試工具
- ab
只能測試單一域名
- http_load
可以測試多個域名,并隨機選擇進行測試
- JMeter
更復雜,可以設置參數眾多,能夠更加靈活的monitor真實用戶訪問,并有繪圖接口、還可以對測試進行記錄,離線重演測試結果。支持壓測多種不同應用。
- siege
能夠模擬比http_load更大的負載,并支持延遲、隨機等特性,可以更好的模擬真實用戶請求,僅用于Web服務測試。
#### 4.2 單組件式測試工具
- TPCC-MySQL
Percona出品,主流MySQL壓測
- sysbench
主流MySQL壓測,支持Lua腳本,同時還支持操作系統和硬件的硬件測試。
### 第5章 總結
基準測試并不是僅僅用來解決業務問題的一種時間,也是一種很好的學習方法。學習如何將問題分解成可以通過基準測試來獲得答案的方法,就和數學課上從文字題目中推到出方程式一樣。首先正確的描述問題,然后選擇合適的基準測試來回答問題。設置基準測試的持續時間和參數,運行測試,收集數據,分析結果數據。
如果經常執行基準測試,那么指定一個原則很有必要。選擇合適的測試工具深入的學習。可以建立一個腳本庫,用于配置基準測試,收集輸出結果、系統性能和狀態,以及分析結果。使用一種熟悉的繪圖工具gnuplot或者R,不用浪費時間使用電子表格,他們即笨重,速度又慢。盡量早和多的使用繪圖的方式,來發現基準測試和系統中的問題和錯誤,你的眼睛是比任何腳本和自動化工具都更有效的發現問題的工具。
- 獻給樂于奉獻的你
- 一、工作感悟
- 1.1 工作感悟
- 1.2 數據庫工作總結
- 二、運維專題(非技術)
- 2.1 公有云運維
- 2.1.1 阿里云采坑記.md
- 三、運維專題(技術類)
- 3.1 Linux(操作系統)
- 3.1.1 常見工作總結
- 3.1.2 常見服務使用和部署
- 3.1.3 操作系統優化
- 3.1.4 常用命令(Centos8)
- 3.2 Docker & K8s(容器技術)
- 3.2.1 Docker
- 1. Docker
- 1-1 容器基礎
- 1-2 部署和加速
- 1-3 常用命令
- 1-4 Dockerfile編寫
- 1-5 容器網絡
- 1-6 數據持久化
- 2. docker-compose
- 2-1 基礎
- 3.2.2 kubernetes
- 1. 導讀-請先看我
- 2. kubeadm部署集群
- 1-1 k8s-1.14-基于calico
- 1-2 k8s-1.17-基于flanne
- 3. 二進制部署集群
- 4. 日常工作及故障處理
- 4-1 常用命令
- 4-2 故障處理
- 3.2.3 依賴服務部署
- 1. Harbor(鏡像倉庫)
- 1-1 harbor-2.1.0(單節點)
- 3.3 CICD(持續集成/部署)
- 3.3.1 GitLab
- 1. 服務部署
- 1-1 Gitlab-CE-13.3.4(單節點)
- 2. Git基礎
- 3.3.2 Ansible
- 1. 服務部署
- 1-2 ansible-2.5(pip部署)
- 3. ansible-playbook
- 3-1 基于Roles的Playbook
- 3-3 循環語法
- 3.3.3 Jnekins
- 1. Jenkins部署
- 1-1 Jenkins-2.65部署
- 1-2 Jenkins-2.249部署
- 2. Jenkins項目初始化
- 3. Jenkins集成
- 3-1 Jenkins-2.65集成Sonar
- 3.4 LB/HA(負載均衡,反向代理)
- 3.4.1 LVS+Keepalive
- 1. LVS為MySQL讀提供負載均衡
- 3.4.2 Pacemaker(HA)
- 1. 常用命令(轉)
- 3.5 Runtime(代碼運行環境)
- 3.5.1 Tomcat(Web中間件)
- 1. Tomcat部署手冊
- 1-1 Tomcat-7.0.76部署
- 2. Tomcat常用腳本
- 3.6 NoSQL(非關系型數據庫)
- 3.6.1 redis(非關系數據庫)
- 1. Redis 基礎
- 2. Redis 4.0變化
- 3. Codis實現Redis的集群
- 4. Redis故障處理
- 5. redis安全第一步
- 6. Redis集群搭建
- 7. CacheCloud部署
- 3.6.1 Redis挑戰
- 3.6.2 MongoDB(文檔數據庫)
- 1. Mongodb基礎
- 1-1 Mongodb4.0新特性
- 1-2 支持多大數據量
- 2. Mongodb安裝
- 2-1 Mac OS安裝Mongodb
- 2-2 Yum安裝Mongodb
- 2-3 二進制安裝Mongodb
- 2-4 docker容器安裝Mongodb
- 2-5 Mongodb 配置文件詳解
- 2-6 Mongodb 生產安全清單
- 2-7 用戶身份認證和授權
- 3. Mongodb副本集
- 3-1 副本集搭建
- 3-2 用戶身份認證與授權
- 4. 日常維護工作
- 4-1 Mongodb磁盤回收
- 4-2 Mongodb備份恢復到任意時間點
- 4-3 Mongodb慢查詢分析
- 4-4 Mongodb版本升級
- 4-5 Mongodb副本集成員狀態
- 4-6 Mongodb備份恢復工具使用
- 4-7 Mongodb服務啟動和停止
- 4-8 修改副本集成員oplog大小
- 4-9 Mongodb 副本集Oplog
- 3.7 MQ(消息隊列)
- 3.7.1 Zookeeper(分布式協調系統)
- 1. ZooKeeper基礎
- 2. ZooKeeper集群搭建
- 2-1 ZK-3.4.10部署
- 3.2 RabbitMQ(消息隊列)
- 1. 服務部署
- 1-1 RabbitMQ-3.8部署
- 2. 常用命令
- 3.8 Monitor(數據收集,監控)
- 3.8.1 Zabbix(運維監控)
- 1. 服務部署
- 1-1 服務端部署
- 1-2 客戶端部署
- 2. 監控服務
- 2-1 監控Apache
- 2-2 監控IIS
- 2-3 監控Ningx
- 2-4 監控Tomcat(6/7/8)
- 2-5 監控WebSphere 7
- 2-6 監控MySQL
- 2-7 監控Oracle
- 2-8 監控SQL Servre
- 2-9 監控Weblogic
- 2-10 監控Windows
- 2-11 自定義監控項
- 3. 告警推送
- 3-1 郵件告警
- 3-2 短信告警
- 3-3 告警推到Syslog
- 4. 日常工作
- 4-1 數據庫優化(TokuDB)
- 4-2 數據庫優化(分區表)
- 4-3 前端定制(Grafana)
- 5. 與Grafana結合
- 3.8.2 ELKBstack(日志收集展示)
- 1. 服務部署
- 1-1 ELK 5.5部署及配置
- 1-1-1 ELKBstack介紹
- 1-1-2 Elasticsearch部署
- 1-1-3 Logstash部署
- 1-1-4 Kibana部署
- 1-1-5 X-pack部署
- 1-1-6 Filebeat部署
- 2. ELK高級配置
- 1. Elasticsearch實戰
- 2. Logstash實戰
- 3. Filebeat實戰
- 5. 引入隊列
- 3.9 Virtualization(虛擬化)
- 3.10 Basic(基礎服務)
- 3.10.1 Piwik-Matomo(用戶行為分析)
- 1. Piwik前期分析
- 2. Piwik介紹和部署
- 2-1 Piwik-3.x版本(早期)
- 3. Piwik 功能配置
- 4. Piwik 模擬數據和壓測
- 5. Piwik運轉原理
- 6. Piwik數據庫模式(一)
- 6-1 第一部分
- 6-2 第二部分
- 3.10.2 Cobbler(系統自動部署)
- 1. Cobbler 可以干什么?
- 2. Cobbler 基礎原理
- 3. Cobbler 安裝
- 3-1 Cobbler-2.8部署
- 4. Cobbler 基礎配置
- 5. Cobbler 配置文件
- 6. 一鍵優化腳本
- 3.10.3 Rsync(數據同步服務)
- 1. Rsync基礎
- 2. 案例:頁面部署(服務端拉取)
- 3.10.4 NFS(共享存儲)
- 1. NFS部署手冊
- 2. 客戶端NFS備份腳本
- 3.10.5 Grafana(可視化)
- 1. 安裝(8.2.x)
- 3.11 Tools(軟件工具)
- 3.11.1 基準測試
- 1. 基準測試方法論
- 2. 壓測工具 - Siege
- 3. 壓測工具 - http_load
- 3.12 DB(關系型數據庫)
- 3.12.1 MySQL(關系數據庫)
- 1. MySQL部署
- 1-1 MySQL-5.7部署
- 1-2 Percona-5.7 + TokuDB 部署
- 2. MySQL復制
- 2-1 MySQL異步復制
- 3. MySQL備份恢復
- 3-1 xtrabackup 備份恢復
- 4. MySQL 高可用
- 4-1 MHA(HA)
- 4-1-1 MHA 架構介紹和原理
- 4-1-2 MHA日常管理
- 4-1-3 MHA 自動Failover
- 4-1-4 MHA常用參數
- 4-1-5 MHA 報錯
- 4-1-6 MHA相關配置文件和腳本
- 4-2 MyCAT
- 4-2-1 MyCAT 介紹和部署
- 4-1-3 MyCAT讀寫分離案例解析
- 5. MySQL 常用腳本
- 5-1 MySQL常用統計語句
- 5-2 MySQL性能分析腳本
- 6. MySQL 日常及故障處理
- 6-1 MySQL死鎖排查
- 6-2 復制故障
- 6-3 MySQL 升級注意事項
- 6-3 MySQL授權
- 3.12.2 Oracle(關系數據庫)
- 1. Oracle部署
- 1-1 Oracle11g單實例部署
- 1-2 Oracle12c單實例部署
- 2. Oracle常用腳本
- 3. Oracle 知識點
- 六、Ansible開源項目
- 6.1 項目初始化手冊
- 6.1.1 Ansible錯誤處理
- 6.1.2 一種預先判斷是否操作的方法
- 6.2 System初始化
- 6.3 Nginx/Tnginx部署
- 6.4 Python部署
- 6.5 PHP部署
- 6.6 MySQL部署
- 6.7 Docker部署
- 6.8 Haproxy部署
- 6.9 Redis部署
- 1. 變量和tags信息
- 3. Redis主從部署
- 4. Redis集群部署
- 5. 清理數據
- 6.10 Software軟件部署
- 6.11 Zabbix部署
- 6.12 Elastic部署
- 6.13 Tomcat
- 6.14 Kafka部署
- 6.15 Zookeeper部署
- 6.16 Etcd集群部署
- 6.17 M3DB部署
- 6.18 Pormetheus部署
- 七、學習資源推薦
- 八、從瞎搞到放棄
- 8.1 CodeQL(語義代碼分析引擎)
- 8.1.1 背景及計劃
- 8.1.2 CodeQL概述
- 8.1.3 簡單部署和使用
- 8.1.4 后續
- 8.2 dbdeployer(輕松部署MySQL)
- 歸檔筆記
- 三、常用服務部署(遷移中)
- 3.4 Nginx & PHP(Web服務)
- 3.4.1 Nginx(Web)
- 1. Nginx基礎和部署
- 2. Nginx 我的一些思考
- 3. Nginx(Web)配置
- 4. Nginx(Proxy)配置
- 5. Nginx日常管理
- 3.4.3 PHP
- 1. PHP 7.1 部署
- 2. PHP5.6 部署
- 4. PHP原理
- 5. PHP 常用模塊
- 二、運維項目實戰(遷移中)
- 2.1 標準化 & 工具化項目
- 2.1.1 系統部署和優化
- 2.1.5 全網日志收集展示平臺項目
- 1. 項目需求
- 2. 整體方案規劃
- 3. 日志收集配置
- 4. 消息緩沖隊列
- 5. 日志處理轉發
- 6. 日志數據展示(待補充)
- 7. ELK安全配置(上)
- 8. ELK安全配置(下)
- 9. 項目總結
- 2.2 高性能Web項目
- 2.2.1 網站需求(完善中)