容器云存儲性能測試概述

1、 容器云存儲性能測試概述 1.1 相關(guān)概念介紹1.1.1 軟件測試分類軟件測試按照測試階段、是否運行程序、是否查看源代碼以及其他方式，可以用下圖所示來描述軟件測試的各種分類。1.1.2 性能測試分類系統(tǒng)的性能是一個很大的概念，覆蓋面非常廣泛，對一個軟件系統(tǒng)而言，包括：執(zhí)行效率、資源占用、系統(tǒng)穩(wěn)定性、安全性、兼容性、可靠性、可擴(kuò)展性等。性能測試是為描述測試對象與性能相關(guān)的特征并對其進(jìn)行評價，而實施和執(zhí)行的一類測試。它主要通過自動化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項性能指標(biāo)進(jìn)行測試。通常大家把性能測試、負(fù)載測試、壓力測試統(tǒng)稱為性能測試。1基準(zhǔn)測試:在給系統(tǒng)施加較低壓力時，查

2、看系統(tǒng)的運行狀況并記錄相關(guān)數(shù)作為基礎(chǔ)。2負(fù)載測試:是指對系統(tǒng)不斷地增加壓力或增加一定壓力下的持續(xù)時間，直到系統(tǒng)的某項或多項性能指標(biāo)達(dá)到安全臨界值，例如某種資源已經(jīng)達(dá)到飽和狀態(tài)等。3壓力測試:壓力測試是評估系統(tǒng)處于或超過預(yù)期負(fù)載時的運行情況，關(guān)注點在于系統(tǒng)在峰值負(fù)載或超出最大載荷情況下的處理能力。4穩(wěn)定性測試:在給系統(tǒng)加載一定業(yè)務(wù)壓力的情況下，使系統(tǒng)運行一段時間，以此檢測系統(tǒng)是否穩(wěn)定。5并發(fā)測試:測試多個用戶同時訪間同一個應(yīng)用、同一個模塊或者數(shù)據(jù)記錄時是否存在死鎖或者其他性能問題。1.1.3 不同視角下的軟件性能用戶視角的軟件性能從用戶的角度來說，軟件性能就是用戶操作軟件的響應(yīng)時間;用戶所體會到

3、的“響應(yīng)時間”既有客觀的成分，也有主觀的成分。例如，用戶執(zhí)行了某個操作，該操作返回大量數(shù)據(jù)，從客觀的角度來說，事務(wù)的結(jié)束應(yīng)該是系統(tǒng)返回所有的數(shù)據(jù)響應(yīng)時間應(yīng)該是從用戶操作開始到所有數(shù)據(jù)返回完成的整個耗時;但從用戶的主觀感知來說，如果采用一種優(yōu)化的數(shù)據(jù)呈現(xiàn)策略，當(dāng)少部分?jǐn)?shù)據(jù)返回之后就立刻將數(shù)據(jù)呈現(xiàn)在用戶面前，則用戶感受到的響應(yīng)時間就會遠(yuǎn)遠(yuǎn)小于實際的事務(wù)響應(yīng)時間。對于典型的交互系統(tǒng)，2s之內(nèi)的響應(yīng)時間通常是被用戶所接受的;如果響應(yīng)時間為5s時，用戶的滿意程度將會受到一定的影響;當(dāng)交易響應(yīng)時間為10s時，那么大多數(shù)用戶將會不耐煩地關(guān)閉交易頁面，顯然這是非常糟糕的用戶體驗。管理員視角的軟件性能管理員視角

4、有時候也就是運維人員的視角。對于運維人員來說，響應(yīng)時間當(dāng)然也很重要，運維方關(guān)注更多的是系統(tǒng)運行是否平穩(wěn)(響應(yīng)時間或者交易吞吐量是否有劇烈波動)，CPU、內(nèi)存、存儲等關(guān)鍵資源是否充足。另外，對于銀行這樣擁有海量用戶和較高交易吞吐量的企業(yè)來說，系統(tǒng)是否具有較好的可擴(kuò)展性是很關(guān)鍵的(這決定了是否能夠通過資源調(diào)配和擴(kuò)充平穩(wěn)度過業(yè)務(wù)高峰)，包括：1系統(tǒng)的響應(yīng)時間2系統(tǒng)狀態(tài)的相關(guān)信息，如CPU、內(nèi)存、應(yīng)用服務(wù)器狀態(tài)、JVM可用內(nèi)存、數(shù)據(jù)庫的狀態(tài)等3系統(tǒng)的可擴(kuò)展性，即處理并發(fā)的能力4系統(tǒng)可能的最大容量和可能的性能瓶頸，通過更換哪些設(shè)備或是進(jìn)行哪些擴(kuò)展能夠提高系統(tǒng)的性能。5長時間運行是否足夠穩(wěn)定，是否能夠不間

5、斷地提供業(yè)務(wù)服務(wù)等。開發(fā)視角的軟件性能開發(fā)人員對性能的關(guān)注點更多的是系統(tǒng)投產(chǎn)上線后，響應(yīng)時間是否達(dá)到了用戶需求說明書中的相關(guān)要求。此外，開發(fā)人員更加關(guān)注編寫代碼的運行效率、數(shù)據(jù)庫訪問是否按照設(shè)想的訪問路徑以及索引設(shè)置是否合理等，包括用戶和管理員關(guān)心的軟件性能。如何通過調(diào)整設(shè)計和代碼實現(xiàn)，或是如何通過調(diào)整系統(tǒng)設(shè)置等方法提高軟件的性能表現(xiàn)。如何發(fā)現(xiàn)并解決軟件設(shè)計和開發(fā)過程中產(chǎn)生的由于多用戶訪問引發(fā)的軟件障，也就是通常所說的“性能瓶頸”和系統(tǒng)中存在的在大量用戶訪問時表現(xiàn)出來的缺陷。1.1.4 性能衡量指標(biāo)響應(yīng)時間請求響應(yīng)時間指的是客戶端發(fā)出請求到得到響應(yīng)的整個過程的時間。這個過程是從客戶端發(fā)起一個請

6、求開始計時，到客戶端接收到從服務(wù)器端返回的響應(yīng)結(jié)果為止計時結(jié)束。在某些工具中，請求響應(yīng)時間通常會被稱為TTLB，即Time to Last Byte，意思是從發(fā)起一個請求開始，到客戶端收到最后一個字節(jié)的響應(yīng)所耗費的時間。請求響應(yīng)時間的單位一般為“秒（s）”或者“毫秒（ms）”。請求響應(yīng)時間的分解如下圖所示：從圖中可以看出，請求響應(yīng)時間為“網(wǎng)絡(luò)響應(yīng)時間”和“應(yīng)用程序與系統(tǒng)響應(yīng)時間”之和，具體由七個部分組成，即（N1+N2+N3+N4）+（A1+A2+A3）。并發(fā)用戶數(shù)并發(fā)用戶數(shù)也經(jīng)常被用來作為衡量系統(tǒng)并發(fā)處理能力的指標(biāo)，并發(fā)用戶數(shù)是指系統(tǒng)可以同時承載的正常使用系統(tǒng)功能的用戶數(shù)量。這個指標(biāo)也經(jīng)常被

7、當(dāng)作衡量系統(tǒng)處理能力的重要指標(biāo)。實際上，籠統(tǒng)地將并發(fā)用戶數(shù)的大小作為衡量系統(tǒng)并發(fā)處理能力的指標(biāo)并不是十分科學(xué)的，因為并發(fā)用戶又可以細(xì)分為在線用戶數(shù)和嚴(yán)格的并發(fā)用戶。在線用戶是指在同一時刻處于登錄狀態(tài)的用戶，在線用戶數(shù)僅僅表明有多少用戶處于登錄狀態(tài)，并不能說明這些用戶正在進(jìn)行操作，在某些情況下，系統(tǒng)在線用戶數(shù)可能比較高，但是每秒處理交易數(shù)量有可能并不高。嚴(yán)格的并發(fā)用戶是指在同一時刻執(zhí)行統(tǒng)一操作的活躍用戶。較少的嚴(yán)格并發(fā)明戶數(shù)可能就會給系統(tǒng)造成較大的壓力，實際上絕大多數(shù)未經(jīng)過性能測試和未做調(diào)優(yōu)的應(yīng)用系統(tǒng)，510個嚴(yán)格并發(fā)用戶就能或多或少地給系統(tǒng)造成性能間題。系統(tǒng)用戶數(shù)是指系統(tǒng)注冊的總用戶數(shù)。三者之

8、間的關(guān)系:系統(tǒng)用戶數(shù)在線用戶數(shù)嚴(yán)格的并發(fā)用戶數(shù)。吞吐量單位時間內(nèi)處理的客戶端請求數(shù)量，直接體現(xiàn)軟件系統(tǒng)的性能承載能力。通常情況下，吞吐率可以用“請求數(shù)/秒”“頁面數(shù)/秒”來衡量。從網(wǎng)絡(luò)角度，吞吐量一般以“字節(jié)/秒”來衡量。TPS（Transaction Per Second）是指每秒鐘系統(tǒng)能夠處理的交易或者事務(wù)的數(shù)量，用來衡量系統(tǒng)業(yè)務(wù)處理能力的重要指標(biāo)。對于一些日交易量比較大的系統(tǒng)，通常在測試報告中用每秒完成多少萬筆或8/12/24小時完成多少萬筆交易來描述系統(tǒng)的業(yè)務(wù)處理能力，這樣可以感覺更直觀。大體來說，對于交互式應(yīng)用，用戶直接的體驗是響應(yīng)時間，通過并發(fā)用戶數(shù)和響應(yīng)時間可以確定系統(tǒng)的性能規(guī)劃

9、，但對于非交互式應(yīng)用，用“吞吐量”來描述我們對系統(tǒng)性能的期望會更加合理。對于交互式應(yīng)用來說，吞吐量指標(biāo)反映的是服務(wù)器承受的壓力。在容量規(guī)劃的測試中，吞吐量是一個重點關(guān)注的指標(biāo)，因為它能夠說明系統(tǒng)級別的負(fù)載能力。另外，在性能調(diào)優(yōu)的過程中，吞吐量指標(biāo)也有重要的價值。如在web系統(tǒng)的性能測試過程中，吞吐量以請求數(shù)/秒 來體現(xiàn)，吞吐量指標(biāo)可以在兩個方面發(fā)揮左右：用于協(xié)助設(shè)計性能測試場景，以及衡量性能測試場景是否達(dá)到了預(yù)期的實際目標(biāo)。用于協(xié)助分析性能瓶頸，吞吐量的限制是性能瓶頸的一種重要表現(xiàn)形式，因此，由針對性的對吞吐量進(jìn)行測試，可以盡快定位到性能瓶頸所在位置。比如說，RBI（rapid bottlen

10、eck identify）方法就主要通過吞吐量測試發(fā)現(xiàn)性能瓶頸。1.2 性能測試方法論1.2.1 性能測試方法1.2.1.1 RBI（rapid bottleneck identify）方法RBI（rapid bottleneck identify）方法是Empirix公司提出的一種用于快速識別系統(tǒng)性能瓶頸的方法。該方法基于以下一些事實：1發(fā)現(xiàn)的80%系統(tǒng)的性能瓶頸都由吞吐量制約。2并發(fā)用戶數(shù)和吞吐量瓶頸之間存在一定的關(guān)聯(lián)。3采用吞吐量測試可以更快速的定位問題。RBI方法首先訪問服務(wù)器上的小頁面和簡單應(yīng)用，從應(yīng)用服務(wù)器，網(wǎng)絡(luò)等基礎(chǔ)的層面上了解系統(tǒng)吞吐量表現(xiàn)。其次選擇不同的場景，設(shè)定不同的并發(fā)用

11、戶數(shù)，使其吞吐量保持基本一致的增長趨勢，通過不斷增加并發(fā)用戶數(shù)和吞吐量，觀察系統(tǒng)的性能表現(xiàn)。在確定具體的性能瓶頸時，RBI將性能瓶頸的定位按照一種“自下而上”的分析方式進(jìn)行分析，首先確定是由并發(fā)還是由吞吐量引發(fā)的性能表現(xiàn)限制，然后從網(wǎng)絡(luò)，數(shù)據(jù)庫，應(yīng)用服務(wù)器和代碼本身4個環(huán)節(jié)確定系統(tǒng)性能具體的瓶頸。RBI方法在性能瓶頸的定位過程中能發(fā)揮良好的作用，其對性能分析和瓶頸定位有很強(qiáng)的借鑒意義。1.2.1.2 性能下降曲線分析法性能下降曲線實際上描述的是性能隨客戶數(shù)量增加而出現(xiàn)下降趨勢的曲線。這里的性能可以是響應(yīng)時間，也可以是吞吐量。性能曲線大體分成以下幾個部分:1性能平坦區(qū)在不進(jìn)行性能調(diào)優(yōu)的情況下所能

12、期望達(dá)到的最佳性能。這個區(qū)域可以被用來做性能基線或者benchmark。2壓力區(qū)應(yīng)用出現(xiàn)性能輕微下降的地方。典型的，最大的建議用戶負(fù)載是壓力區(qū)域的開始。3性能拐點性能開始急劇下降的點。這幾個區(qū)域?qū)嶋H上明確標(biāo)識了系統(tǒng)性能最優(yōu)秀的區(qū)間。系統(tǒng)性能開始變壞的區(qū)間，以及性能出現(xiàn)急劇下降的點。對于性能測試來說，找到這些區(qū)間和拐點，就可以找到性能瓶頸產(chǎn)生的地方。1.2.2 壓力測試工具針對不同場景，一般有不同層面的性能測試工具。系統(tǒng)層面，比如Linux環(huán)境下，針對不同的系統(tǒng)組件存在不同的系統(tǒng)壓測工具。最常見的是系統(tǒng)的sysbench組件包所包含的工具。下圖是性能領(lǐng)域領(lǐng)域?qū)＜褺rendan Gregg的提供l

13、inux system bench tools圖，供參考。命令的詳細(xì)用法可以通過man查閱。應(yīng)用層面，目前web應(yīng)用整體一般采用loadrunner或者jmeter進(jìn)行壓力測試。（loadrunner可以通過錄制操作自動生成測試腳本。Jmeter可以使用badboy錄制操作步驟，生成jmeter運行腳本）。對于沒有web的一些后端應(yīng)用，特別是基于webservice的微服務(wù)，一般采用soapui或者postman進(jìn)行壓力測試（soapui和postman的另一個強(qiáng)大功能是可以根據(jù)測試結(jié)果自動創(chuàng)建樁代碼服務(wù)器，這在存在大量關(guān)聯(lián)應(yīng)用的環(huán)境下，尤為有用）。1.2.3 性能觀測工具在Linux環(huán)境下，

14、存在不同層面的性能觀測工具，用于分析不同層面的系統(tǒng)性能。比如常見的nmon、top命令用于系統(tǒng)全局性的觀測，sar用于統(tǒng)計性的觀測。下面是Brendan Gregg提供的圖，供參考。中間件、數(shù)據(jù)庫層面也有類似工具如WAS（IBM WebSphere Application Server），就有自帶的TPV（Tivoli Performance Viewer）WAS外部監(jiān)控工具PTT（WebSphere Application Server Performance Tuning Toolkit）這些監(jiān)控工具會提供詳細(xì)的KPI監(jiān)控數(shù)據(jù)，通過分析相關(guān)KPI，我們可以確定性能瓶頸或者找到性能瓶頸的可疑

15、點。1.2.4 性能分析方法1.2.4.1 Ad Hoc核對清單法當(dāng)需要檢查和調(diào)試系統(tǒng)時，技術(shù)支持人員通常會花一點時間一步步地過一遍核對清單。一個典型的場景，在產(chǎn)品環(huán)境部署新的服務(wù)器或應(yīng)用時，技術(shù)支持人員會花半天的時間來檢查一遍系統(tǒng)在真實壓力下的常見問題。該類核對清單就是Ad Hoc（基于對該系統(tǒng)類型的經(jīng)驗和之前所遇到的問題所羅列的清單）。舉個例子，如下是核對清單中的一項:運行 iostat-x1檢查await列。如果該列在負(fù)載下持續(xù)超過10(ms)，那么說明磁盤太慢或是磁盤過載。一份核對清單會包含很多這樣的檢查項目。這類清單能在最短的時間內(nèi)提供最大的價值，一般需要頻繁更新以保證反映當(dāng)前狀態(tài)。

16、這類清單處理的多是修復(fù)方法容易記錄的問題，例如設(shè)置可調(diào)參數(shù)，而不是針對源 代碼或環(huán)境做定制的修復(fù)。Ad Hoc核對清單能有效保證所有人都知道如何檢查最糟糕的問題，能覆蓋到所有顯而易見的問題。核對清單必須寫得清楚而規(guī)范，詳細(xì)說明如何辨別每一個問題和如何做修復(fù)。舉例：Brendan Gregg提供的60秒針對liunx做基礎(chǔ)性能判斷的命令列表，如下：再比如，在一個典型的基于WAS的web應(yīng)用場景下，下圖即可認(rèn)為是它的Ad Hoc核對清單。1.2.4.2 USE方法( utilization、saturation、errors)該方法的核心是對于所有的資源，查看它的使用率、飽和度和錯誤。術(shù)語說明：1

17、資源:所有服務(wù)器物理元器件（CPU、總線），某些軟件資源也能算在內(nèi)。2使用率:在規(guī)定的時間間隔內(nèi)，資源用于服務(wù)工作的時間百分比。雖然資源繁忙，但是資源還有能力接受更多的工作，不能接受更多工作的程度被視為飽和度。3飽和度:資源不能再服務(wù)更多額外工作的程度，通常有等待隊列。4錯誤:錯誤事件的個數(shù)。一旦資源的容量達(dá)到100的使用率，就無法接受更多的工作，資源或者會把工作進(jìn)行排隊(飽和)，或者會返回錯誤。USE方法會將分析引導(dǎo)到一定數(shù)量的關(guān)鍵指標(biāo)上，這樣可以盡快地核實所有的系統(tǒng)資源。實操過程如下：這個方法辨別出的很可能是系統(tǒng)瓶頸問題。不過，一個系統(tǒng)可能不只面臨一個性能間題，因此你可能一開始就能找到問題

18、，但所找到的回題并非你關(guān)心的那個。在根據(jù)需要返回USE方法遍歷其他資源之前，每個發(fā)現(xiàn)可以用更多的方法進(jìn)行調(diào)查。USE方法的第一步是要建一張資源列表，要盡可能完整。下面是一張服務(wù)器通常的資源列表范例：1CPU:插槽、核、硬件線程(虛擬CPU)2內(nèi)存:DRAM3網(wǎng)絡(luò)接口:以太網(wǎng)端口4存儲設(shè)備:磁盤5控制器:存儲、網(wǎng)絡(luò)6互聯(lián):CPU、內(nèi)存、IO一旦你掌握了資源的列表，就可以采集這三類指標(biāo):使用率、飽和度，以及錯誤。比如:1CPU使用率（vmstat 1）2CPU飽和度（即運行隊列長度 vmstat 1）3內(nèi)存使用率（free -m）4內(nèi)存飽和度（匿名換頁或者線程換出再或者OOM）5網(wǎng)絡(luò)接口使用率（s

19、ar n DEV 1）6存儲使用率（設(shè)備繁忙百分比iostat d x 1）7存儲飽和度（等待隊列長度iostat d x 1）8存儲設(shè)備IO（dmesg smartctl）數(shù)據(jù)采集后，根據(jù)如下的建議找到瓶頸并進(jìn)行深入分析：使用率:100%的使用率通常是瓶頸的信號(檢查飽和度并確認(rèn)其影響)。使用率超過60可能會是問題，基于以下理由:時間間隔的均值，可能掩蓋了100%使用率的短期爆發(fā)，另外，一些資源，諸如硬盤(不是CPU)，通常在操作期間是不能被中斷的，即使做的是優(yōu)先級較高的工作。隨著使用率的上升，排隊延時會變得更頻繁和明顯。飽和度:任何程度的飽和都是問題(非零)。飽和程度可以用排隊長度或者排隊

20、所花的時間來度量。錯誤:錯誤都是值得研究的，尤其是隨著錯誤增加性能會變差的那些錯誤。1.2.4.3 延時分析法延時分析檢查完成一項操作所用的時間，然后把時間再分成小的時間段，接著對有著最大延時的時間段做再次的劃分，最后定為并量化問題的根本原因。一般情況下，延時分析需要深入到軟件棧中的各層去尋找延時問題的原因。比如說常見的web應(yīng)用，可以如下圖所示，先粗略的劃分各組件消耗時間。再深入到各組件內(nèi)部詳細(xì)分析延時。1.2.5 性能分析遵循的常見原則1.2.5.1 2/5/8原則所謂響應(yīng)時間的“2-5-8原則”，簡單地說:當(dāng)用戶能夠在2s以內(nèi)得到響應(yīng)時，會感覺系統(tǒng)的響應(yīng)很快;當(dāng)用戶在2至5s得到響應(yīng)時，

21、會感覺系統(tǒng)的響應(yīng)速度還可以;當(dāng)用戶在5至8s得到響應(yīng)時，會感覺系統(tǒng)的響應(yīng)速度很慢，但是還可以接受;而當(dāng)用戶在超過8s后仍然無法得到響應(yīng)時，會感覺系統(tǒng)糟透了，或者認(rèn)為系統(tǒng)已經(jīng)失去響應(yīng)，而選擇離開這個Web站點，或者發(fā)起第二次請求。1.2.5.2 二八原則二八定律也叫巴萊多定律，是19世紀(jì)末20世紀(jì)初意大利經(jīng)濟(jì)學(xué)家巴萊多發(fā)明的。該定律的主要內(nèi)容為:在任何一組東西中，最重要的只占其中一小部分，約20;其余80的盡管是多數(shù)，卻是次要的，因此又稱二八法則。用于減少風(fēng)險、抓住重點進(jìn)行更多的測試:用戶80的時間在使用軟件產(chǎn)品中20的功能?！爸攸c測試”就是測試這20的功能，而其他80的功能屬于優(yōu)先級低的測試范

22、圍，占20的測試資源。實例:對測試強(qiáng)度估算基本概念:每個工作日80的業(yè)務(wù)在20的時間內(nèi)完成。例如每天工作8h，那么每天80的業(yè)務(wù)在8201.6h內(nèi)完成。二八原則其他含義80的錯誤是由20的模塊引起的。站在用戶角度，并非研發(fā)實現(xiàn)的角度出發(fā)，正確地選擇重要模塊作為測試重點將不會偏離方向。80的測試成本花在20的軟件模塊中。設(shè)計用例時需要將時間傾斜花在復(fù)雜的20核心模塊上，從而設(shè)計更高效的測試用例。80%的測試時間花在20%的軟件模塊中。軟件測試執(zhí)行過程中需要將時間傾斜在重要模塊的測試用例中，從而使測試更加有效，及時發(fā)現(xiàn)bug。1.2.5.3 由易到難原則查找瓶頸時可按以下由易到難的順序，對于系統(tǒng)運

23、維人員來說，一般習(xí)慣于從下往上，從底層系統(tǒng)開始入手分析。比如：服務(wù)器硬件瓶頸網(wǎng)絡(luò)瓶頸(對局域網(wǎng)，可以不考慮)服務(wù)器操作系統(tǒng)瓶頸(參數(shù)配置)中間件瓶頸(參數(shù)配置、數(shù)據(jù)庫、Web服務(wù)器等)應(yīng)用瓶頸(SQL語句、數(shù)據(jù)庫設(shè)計、業(yè)務(wù)邏輯、算法等)。而對應(yīng)用開發(fā)人員來說，一般習(xí)慣于從熟悉的應(yīng)用層面開始分析，從上往下進(jìn)行分析。1.2.6 性能調(diào)優(yōu)基本原理關(guān)于如何提高性能，從本質(zhì)上說只有兩個原則，所有的調(diào)優(yōu)方案最終從原理上說都是基于這兩個原則。比如說應(yīng)用設(shè)計中各種緩存的應(yīng)用，就是提高IO的操作效率。再比如說各類池（連接池、線程池）的大規(guī)模使用，也是為了減少資源創(chuàng)建和銷毀的動作。1.2.6.1 減少操作步驟1.2.6.2 提高操作效率1.2.7 性能調(diào)優(yōu)遵循的常見原則性能調(diào)優(yōu)是為了改善系統(tǒng)某些方面的性能而對系統(tǒng)軟件或者硬件進(jìn)行的修改。在性能測試調(diào)優(yōu)過程中需要遵循以下原則：1有明確的性能測試目標(biāo)。2在每次調(diào)優(yōu)前，要盡可能對假設(shè)做出清晰的、明確的表述。3每次調(diào)優(yōu)僅執(zhí)行一個配置變更。在每次調(diào)優(yōu)后，使用相同的測試場景，在盡可能一致的后臺數(shù)據(jù)環(huán)境進(jìn)行測試，執(zhí)行結(jié)果要與基線對比分析，確認(rèn)解決方案是否有效并關(guān)注是否帶來其他問題。先整體后局部，層層剝離，即先調(diào)系統(tǒng)(操作系統(tǒng)、中間件)、網(wǎng)絡(luò)，再調(diào)數(shù)據(jù)庫，最后調(diào)整應(yīng)用系統(tǒng)。性能調(diào)優(yōu)的整體過程如下圖:1.3 容器云存儲性能測試1.3.1 容器云存儲介紹