性能测试四十五：性能测试策略
1、項(xiàng)目具體需求,及業(yè)務(wù)場景：關(guān)注真實(shí)用戶會(huì)是怎樣的一個(gè)業(yè)務(wù)場景，確定用戶的用戶習(xí)慣。
2、指標(biāo)：響應(yīng)時(shí)間在多少以內(nèi)，并發(fā)數(shù)多少，tps多少，總tps多少，穩(wěn)定性交易總量多少，事務(wù)成功率，交易波動(dòng)范圍，穩(wěn)定運(yùn)行時(shí)長，資源利用率，測哪些交易，哪些接口,測試哪些場景。
3、環(huán)境：生產(chǎn)環(huán)境服務(wù)器數(shù)量，測試環(huán)境服務(wù)器數(shù)量，按照資源配比得出測試指標(biāo)。
4、協(xié)議：系統(tǒng)用什么協(xié)議進(jìn)行通訊。
5、壓力機(jī)數(shù)量：如果并發(fā)用戶數(shù)太多，需要把壓力發(fā)到不同的壓力機(jī)，不然可能會(huì)存在壓力機(jī)瓶頸問題，導(dǎo)致tps和響應(yīng)時(shí)間抖動(dòng)。
6、交易占比：分析線上日志得出tps占比。
7、系統(tǒng)架構(gòu)：請求流經(jīng)過哪些環(huán)節(jié)，壓測時(shí)監(jiān)控這些環(huán)節(jié)。
測試
1、基準(zhǔn)：一個(gè)用戶迭代100次，關(guān)注響應(yīng)時(shí)間，事務(wù)成功率100%。
2、負(fù)載：10個(gè)用戶跑10分鐘，關(guān)注響應(yīng)時(shí)間，事務(wù)成功率100%。
3、容量：估算一個(gè)總tps，根據(jù)公式計(jì)算出每個(gè)交易的pacing和vu，獲取系統(tǒng)最大處理能力（最優(yōu)容量），再令外測出三個(gè)梯度作為對比（兩組小于最優(yōu)容量，一組大于最優(yōu)容量），四組容量VU等差，tps等差，對比每組容量實(shí)際占比和測試占比（越接近越能模擬真實(shí)場景），關(guān)注響應(yīng)時(shí)間，總tps，tps，事務(wù)成功率，AP cpu利用率，DB cpu利用率，線程死鎖，數(shù)據(jù)庫死鎖。
???? 其中響應(yīng)時(shí)間應(yīng)小于負(fù)載測試時(shí)間，總tps應(yīng)約等于預(yù)估總tps（相差不超過10是正常的），每個(gè)交易的tps應(yīng)接近預(yù)估總tps*占比，事務(wù)成功率100%，AP cpu小于60%，DB cpu小于80%。dump線程棧檢測是否有線程死鎖，查看數(shù)據(jù)庫日志看是否有數(shù)據(jù)庫死鎖。
4、穩(wěn)定性：采取最優(yōu)容量的80%作為壓力持續(xù)運(yùn)行24小時(shí)，觀察系統(tǒng)長時(shí)間運(yùn)行的性能表現(xiàn)，關(guān)注響應(yīng)時(shí)間，tps，總tps，事務(wù)成功率，交易總數(shù)，觀察是否有內(nèi)存溢出（堆溢出，棧溢出，持久代溢出），cpu利用率是否達(dá)標(biāo)，mem是否不持續(xù)增長，是否能正常觸發(fā)fullgc，gc時(shí)間，gc頻率， fullgc時(shí)間，fullgc頻率（重點(diǎn)關(guān)注，JVM調(diào)優(yōu)就是為了減少fullgc頻率）。
壓測中遇到的性能問題及解決辦法
一、測試過程中cpu過高
1、用vmstat實(shí)時(shí)監(jiān)控cpu使用情況。很小的壓力AP cpu卻到了80%多，指標(biāo)是不能超過60%。
2、分析是use cpu過高還是sys cpu過高，常見的是use cpu使用過高。
3、如果是sys cpu使用過高，先把消耗cpu最多的進(jìn)程找出來（top命令），再找到該線程下消耗cpu過高的是哪幾個(gè)線程，再把該線程轉(zhuǎn)換成16進(jìn)制，再用jstack命令來dump線程棧，看這個(gè)線程棧在調(diào)用什么東西導(dǎo)致use cpu過高。
二、內(nèi)存溢出（堆溢出、棧溢出、持久代溢出）
1、堆內(nèi)存溢出
1)穩(wěn)定性壓測一段時(shí)間后，LR報(bào)錯(cuò)，日志報(bào)java.lang.OutOfMemoryError.Java heap space。
2)用jmap -histo pid命令dump堆內(nèi)存使用情況，查看堆內(nèi)存排名前20個(gè)對象，看是否有自己應(yīng)用程序的方法，從最高的查起，如果有則檢查該方法是什么原因造成堆內(nèi)存溢出。
3)如果前20里沒有自己的方法，則用jmap -dump來dump堆內(nèi)存，在用MAT分析dump下來的堆內(nèi)存，分析導(dǎo)出內(nèi)存溢出的方法。
4)如果應(yīng)用程序的方法沒有問題，則需要修改JVM參數(shù)，修改xms，xmx，調(diào)整堆內(nèi)存參數(shù)，一般是增加堆內(nèi)存。
2、棧內(nèi)存溢出
1)穩(wěn)定性壓測一段時(shí)間后，LR報(bào)錯(cuò)，日志報(bào)Java.Lang.StackOverflowError。
2)修改jvm參數(shù)，將xss參數(shù)改大，增加棧內(nèi)存。
3)棧溢出一定是做批量操作引起的，減少批處理數(shù)據(jù)量。
3、持久代溢出
1)穩(wěn)定性壓測一定時(shí)間后，日志報(bào)Java.Lang.OutOfMenoryError.PermGen Space。
2)這種原因是由于類、方法描述、字段描述、常量池、訪問修飾符等一些靜態(tài)變量太多，將持久代占滿導(dǎo)致持久代溢出。
3)修改jvm配置，將XX:MaxPermSize=256參數(shù)調(diào)大。盡量減少靜態(tài)變量。
三、線程死鎖
1、容量測試壓測一段時(shí)間后，LR報(bào)連接超時(shí)。
2、造成這種現(xiàn)象的原因很多，比如帶寬不夠，中間件線程池不夠用，數(shù)據(jù)庫連接池不夠，連接數(shù)占滿等都會(huì)造成連接不上而報(bào)超時(shí)錯(cuò)誤。
3、jstack命令dump線程棧，搜索線程棧里有沒有block，如果有的話就是線程死鎖，找到死鎖的線程，分析對應(yīng)的代碼。
四、數(shù)據(jù)庫死鎖
1、容量測試壓測一段時(shí)間后，LR報(bào)連接超時(shí)。
2、造成這種現(xiàn)象的原因很多，比如帶寬不夠，中間件線程池不夠用，數(shù)據(jù)庫連接池不夠，連接數(shù)占滿等都會(huì)造成連接不上而報(bào)超時(shí)錯(cuò)誤。
3、數(shù)據(jù)庫日志中搜索block，能搜到block的話就是存在數(shù)據(jù)庫死鎖，找到日志，查看對應(yīng)的sql，優(yōu)化造成死鎖的sql。
五、數(shù)據(jù)庫連接池不釋放
1、容量測試壓測一段時(shí)間后，LR報(bào)連接超時(shí)。
2、造成這種現(xiàn)象的原因很多，比如帶寬不夠，中間件線程池不夠用，數(shù)據(jù)庫連接池不夠，連接數(shù)占滿等都會(huì)造成連接不上而報(bào)超時(shí)錯(cuò)誤。
3、去數(shù)據(jù)庫查看應(yīng)用程序到數(shù)據(jù)庫的連接有多少個(gè)（ show full processlist），假如應(yīng)用程序里面配置的數(shù)據(jù)庫連接為30，在數(shù)據(jù)庫查看應(yīng)用程序到數(shù)據(jù)庫的連接也是30，則表示連接池占滿了。將配置改成90試試，去數(shù)據(jù)庫看如果連接到了90，則可以確定是數(shù)據(jù)庫連接池不釋放導(dǎo)致的。查看代碼，數(shù)據(jù)庫連接部分是不是有創(chuàng)建連接但是沒有關(guān)閉連接的情況。基本就是這種情況導(dǎo)致的，修改代碼即可。
六、TPS上不去
1、壓力大的時(shí)候tps頻繁抖動(dòng)，導(dǎo)致總tps上不去。查看是否有fullgc（tail -f gc_mSrv1.log | grep full）。
2、pacing設(shè)置太小也會(huì)導(dǎo)致tps上不去，對抖動(dòng)大的交易多增加點(diǎn)用戶即可。
3、tps抖動(dòng)，單壓抖動(dòng)大的交易，發(fā)現(xiàn)很平穩(wěn)，這時(shí)懷疑是不是壓力太大導(dǎo)致，所以發(fā)容量的時(shí)候把壓力最大的那只交易分到其他壓力機(jī)，然后發(fā)現(xiàn)tps不抖動(dòng)了。注意：多臺(tái)壓力機(jī)只影響tps抖動(dòng)，不會(huì)影響服務(wù)器的cpu。
4、看響應(yīng)時(shí)間有沒有超時(shí)，看用戶數(shù)夠不夠。
七、服務(wù)器壓力不均衡（相差1%-2%是正常的）
1、跑最優(yōu)容量的時(shí)候，四臺(tái)AP只有一臺(tái)cpu超過60%，其他三臺(tái)都在60%以下。
2、查看服務(wù)器是否有定時(shí)任務(wù)。
3、查看是否存在壓力機(jī)瓶頸。
4、是否存在帶寬瓶頸（局域網(wǎng)不存在此問題）。
5、查看部署的版本，配置是否一樣。
6、可能別人也在用這些AP，因?yàn)橥慌_(tái)物理機(jī)上有很多虛擬機(jī)，因?yàn)閯e人先用，資源被別人先占了。
八、fullgc時(shí)間太長
1、跑容量和穩(wěn)定性的時(shí)候，出現(xiàn)LR報(bào)請求超時(shí)錯(cuò)誤，查看后臺(tái)日志是fullgc了，看LR幾點(diǎn)報(bào)的錯(cuò)和日志里fullgc的時(shí)間是否對應(yīng)，fullgc會(huì)暫停整個(gè)應(yīng)用程序，導(dǎo)致LR前端沒響應(yīng)，所以報(bào)錯(cuò)，這時(shí)可以減少old代內(nèi)存，從而減少fullgc時(shí)間，減少fullgc時(shí)間LR就不會(huì)報(bào)錯(cuò)，讓用戶幾乎感覺不到應(yīng)用程序暫停。
2、四臺(tái)AP輪流著full gc（部分server fullgc，其他server也會(huì)fullgc），這時(shí)可以制定策略讓不同的server不同時(shí)fullgc，或者等夜間交易量少時(shí)寫定時(shí)任務(wù)重啟服務(wù)。
十、系統(tǒng)性能指標(biāo)
1）業(yè)務(wù)指標(biāo)：主要包括并發(fā)用戶數(shù)、響應(yīng)時(shí)間、處理能力。
| 指標(biāo) | 定義 | 簡稱 | 標(biāo)準(zhǔn) |
| 交易響應(yīng)時(shí)間 | 指用戶從客戶端發(fā)起一個(gè)請求開始，到客戶端接收到從服務(wù)器端返回的響應(yīng)結(jié)束，整個(gè)過程所耗費(fèi)的時(shí)間。 | Response Time: RT | 對于在線實(shí)時(shí)交易： 互聯(lián)網(wǎng)企業(yè)：500毫秒以下，例如淘寶業(yè)務(wù)10毫秒左右。 金融企業(yè)：1秒以下為佳，部分復(fù)雜業(yè)務(wù)3秒以下。 保險(xiǎn)企業(yè)：3秒以下為佳。 制造業(yè)：5秒以下為佳。 對于批量交易： 不同數(shù)據(jù)量結(jié)果是不一樣的，大數(shù)據(jù)量的情況下，2小時(shí)內(nèi)完成。 |
| 系統(tǒng)處理能力 | 指系統(tǒng)在利用系統(tǒng)硬件平臺(tái)和軟件平臺(tái)進(jìn)行信息處理的能力。 系統(tǒng)處理能力通過系統(tǒng)每秒鐘能夠處理的交易數(shù)量來評(píng)價(jià)，交易有兩種理解：一是業(yè)務(wù)人員角度的一筆業(yè)務(wù)過程；二是系統(tǒng)角度的一次交易申請和響應(yīng)過程。前者稱為業(yè)務(wù)交易過程，后者稱為事務(wù)。兩種交易指標(biāo)都可以評(píng)價(jià)應(yīng)用系統(tǒng)的處理能力。一般建議與系統(tǒng)交易日志保持一致，以便于統(tǒng)計(jì)業(yè)務(wù)量或者交易量。 | HPS（Hits Per Second） ：每秒點(diǎn)擊次數(shù)，單位是次/秒。 TPS（Transaction per Second）：系統(tǒng)每秒處理交易數(shù)，單位是筆/秒。 QPS（Query per Second）：系統(tǒng)每秒處理查詢次數(shù)，單位是次/秒。 對于互聯(lián)網(wǎng)業(yè)務(wù)中，如果某些業(yè)務(wù)有且僅有一個(gè)請求連接，那么TPS=QPS=HPS。 一般情況下，用TPS來衡量整個(gè)業(yè)務(wù)流程，用QPS來衡量接口查詢次數(shù)，用HPS來表示對服務(wù)器點(diǎn)擊請求。 | 無論TPS、QPS、HPS,此指標(biāo)是衡量系統(tǒng)處理能力非常重要的指標(biāo)，越大越好。 |
| 并發(fā)用戶數(shù) | 指在同一時(shí)刻內(nèi)，登錄系統(tǒng)并進(jìn)行業(yè)務(wù)操作的用戶數(shù)量。在測試中，采用虛擬用戶來模擬現(xiàn)實(shí)中用戶進(jìn)行業(yè)務(wù)操作。 | Virtual User: VU | 一般情況下，性能測試是將系統(tǒng)處理能力容量測出來，而不是測試并發(fā)用戶數(shù)，除了服務(wù)器長連接可能影響并發(fā)用戶數(shù)外，系統(tǒng)處理能力不受并發(fā)用戶數(shù)影響，可以用最小的用戶數(shù)將系統(tǒng)處理能力容量測試出來，也可以用更多的用戶將系統(tǒng)處理能力容量測試出來。 |
| 錯(cuò)誤率 | 指系統(tǒng)在負(fù)載情況下，失敗交易的概率。 錯(cuò)誤率＝(失敗交易數(shù)/交易總數(shù))*100%。 穩(wěn)定性較好的系統(tǒng)，其錯(cuò)誤率應(yīng)該由超時(shí)引起，即為超時(shí)率。 | Failure Ratio: FR | 不同系統(tǒng)對錯(cuò)誤率的要求不同，但一般不超出千分之六，即成功率不低于99.4%。 |
?
2）資源指標(biāo)：CPU資源利用率、內(nèi)存利用率、磁盤I/O、網(wǎng)絡(luò)I/O、內(nèi)核參數(shù)(信號(hào)量、打開文件數(shù))等。
| 指標(biāo) | 定義 | 簡稱 | 標(biāo)準(zhǔn) |
| CPU | 中央處理器是一塊超大規(guī)模的集成電路，是一臺(tái)計(jì)算機(jī)的運(yùn)算核心（Core）和控制核心（ Control Unit）。它的功能主要是解釋計(jì)算機(jī)指令以及處理計(jì)算機(jī)軟件中的數(shù)據(jù)。 | Central Processing Unit：CPU | CPU指標(biāo)主要指的CPU利用率，包括用戶態(tài)(user)、系統(tǒng)態(tài)(sys)、等待態(tài)(wait)、空閑態(tài)(idle)。 CPU利用率要低于業(yè)界警戒值范圍之內(nèi)，即小于或者等于75%; CPU sys%小于或者等于30%,? CPU wait%小于或者等于5%。 CPU Load要小于CPU 核數(shù)。 |
| 內(nèi)存 | 內(nèi)存是計(jì)算機(jī)中重要的部件之一，它是與CPU進(jìn)行溝通的橋梁。計(jì)算機(jī)中所有程序的運(yùn)行都是在內(nèi)存中進(jìn)行的，因此內(nèi)存的性能對計(jì)算機(jī)的影響非常大。 | Memory就是內(nèi)存的簡稱 | 現(xiàn)代的操作系統(tǒng)為了最大利用內(nèi)存，在內(nèi)存中存放了緩存，因此內(nèi)存利用率100%并不代表內(nèi)存有瓶頸，衡量系統(tǒng)內(nèi)有有瓶頸主要靠SWAP（與虛擬內(nèi)存交換）交換空間利用率，一般情況下，SWAP交換空間利用率要低于70%,太多的交換將會(huì)引起系統(tǒng)性能低下。 |
| 磁盤吞吐量 | 指在無磁盤故障的情況下單位時(shí)間內(nèi)通過磁盤的數(shù)據(jù)量。 | Disk Throughput | 磁盤指標(biāo)主要有每秒讀寫多少兆，磁盤繁忙率，磁盤隊(duì)列數(shù)，平均服務(wù)時(shí)間，平均等待時(shí)間，空間利用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的的重要依據(jù)，一般情況下，磁盤繁忙率要低于70%。 |
| 網(wǎng)絡(luò)吞吐量 | 指在無網(wǎng)絡(luò)故障的情況下單位時(shí)間內(nèi)通過的網(wǎng)絡(luò)的數(shù)據(jù)數(shù)量。單位為Byte/s。用于衡量系統(tǒng)對于網(wǎng)絡(luò)設(shè)備或鏈路傳輸能力的需求。 當(dāng)網(wǎng)絡(luò)吞吐量指標(biāo)接近網(wǎng)絡(luò)設(shè)備或鏈路最大傳輸能力時(shí)，則需要考慮升級(jí)網(wǎng)絡(luò)設(shè)備。 | Network Throughput | 網(wǎng)絡(luò)吞吐量指標(biāo)主要有每秒有多少兆流量進(jìn)出，一般情況下不能超過設(shè)備或鏈路最大傳輸能力的70%。 |
3）中間件指標(biāo)：常用的中間件例如Tomcat、Weblogic等指標(biāo)主要包括JVM, ThreadPool, JDBC。
| 指標(biāo) | 二級(jí)指標(biāo) | 解釋 | 單位 |
| GC | GC頻率 | java虛擬機(jī)垃圾部分回收頻率 | 每秒多少次 |
| Full GC頻率 | java虛擬機(jī)垃圾完全回收頻率 | 每小時(shí)多少次 | |
| Full GC平均時(shí)長 | 用于垃圾完全回收的平均時(shí)長 | 秒 | |
| Full GC最大時(shí)長 | 用于垃圾完全回收的最大時(shí)長 | 秒 | |
| ThreadPool | Active Thread Count | 活動(dòng)的線程數(shù) | 個(gè) |
| Pending User Request | 處于排隊(duì)的用戶請求個(gè)數(shù) | 個(gè) | |
| JDBC | JDBC Active Connection | JDBC活動(dòng)連接數(shù) | 個(gè) |
標(biāo)準(zhǔn)
當(dāng)前正在運(yùn)行的線程數(shù)不能超過設(shè)定的最大值。一般情況下系統(tǒng)性能較好的情況下，線程數(shù)最小值設(shè)置50和最大值設(shè)置200比較合適。
當(dāng)前運(yùn)行的JDBC連接數(shù)不能超過設(shè)定的最大值。一般情況下系統(tǒng)性能較好的情況下，JDBC最小值設(shè)置50和最大值設(shè)置200比較合適。
GC頻率不能頻繁，特別是FULL GC更不能頻繁，一般情況下系統(tǒng)性能較好的情況下，JVM最小堆大小和最大。
?
4）數(shù)據(jù)庫指標(biāo)：SQL、吞吐量、命中率、鎖。
| 指標(biāo) | 二級(jí)指標(biāo) | 解釋 | 單位 |
| SQL | 耗時(shí) | 執(zhí)行SQL耗時(shí) | 微秒 |
| 吞吐量 | QPS | 每秒查詢次數(shù) | 個(gè) |
| TPS | 每秒事務(wù)次數(shù) | 個(gè) | |
| 命中率 | Key Buffer命中率 | 索引緩沖區(qū)命中率 | 百分之 |
| InnoDB Buffer命中率 | InnoDB緩沖區(qū)命中率 | 百分之 | |
| Query Cache命中率 | 查詢緩存命中率 | 百分之 | |
| Table Cache命中率 | 表緩存命中率 | 百分之 | |
| Thread Cache命中率 | 線程緩存命中率 | 百分之 |
標(biāo)準(zhǔn)
SQL耗時(shí)越小越好，一般情況下微秒級(jí)別。
命中率越高越好，一般情況下不能低于95%。
鎖等待次數(shù)越低越好，等待時(shí)間越短越好。
?
5）前端指標(biāo)：頁面加載時(shí)間、頁面數(shù)量、網(wǎng)絡(luò)時(shí)間（DNS，連接時(shí)間、傳輸時(shí)間等）。
| 指標(biāo) | 二級(jí)指標(biāo) | 解釋 | 單位 |
| 頁面展示 | 首次顯示時(shí)間 | 在瀏覽器地址欄輸入U(xiǎn)RL按回車到用戶看到網(wǎng)頁的第一個(gè)視覺標(biāo)志為止 | 毫秒 |
| OnLoad事件時(shí)間 | 瀏覽器觸發(fā)onLoad事件的時(shí)間，當(dāng)原始文檔和所有引用的內(nèi)容完全下載后才會(huì)觸發(fā)這個(gè)事件 | 毫秒 | |
| 完全載入的時(shí)間 | 所有onLoad JavaScript 處理程序執(zhí)行完畢，所有動(dòng)態(tài)的或延遲加載的內(nèi)容都通過這些處理程序觸發(fā)的時(shí)間 | 毫秒 | |
| 頁面數(shù)量 | 頁面大小 | 整個(gè)頁面大小 | KB |
| 請求數(shù)量 | 從網(wǎng)站下載資源時(shí)所有網(wǎng)絡(luò)請求的總數(shù)，盡量少 | 次 | |
| 網(wǎng)絡(luò)所花時(shí)間 | DNS時(shí)間 | DNS查找時(shí)間 | 毫秒 |
| 連接時(shí)間 | 瀏覽器與Web服務(wù)器建立TCP/IP連接的時(shí)間 | 毫秒 | |
| 服務(wù)器時(shí)間 | 服務(wù)器處理時(shí)間 | 毫秒 | |
| 傳輸時(shí)間 | 內(nèi)容傳輸所用時(shí)間 | 毫秒 | |
| 等待時(shí)間 | 等待某個(gè)資源釋放的時(shí)間 | 毫秒 |
標(biāo)準(zhǔn)
頁面要盡可能小及壓縮。
頁面展示和花費(fèi)時(shí)間越短越好。
?
6）穩(wěn)定性指標(biāo)
最短穩(wěn)定時(shí)間：系統(tǒng)按照最大容量的80%或標(biāo)準(zhǔn)壓力（系統(tǒng)的預(yù)期日常壓力）情況下運(yùn)行，能夠穩(wěn)定運(yùn)行的最短時(shí)間。?
一般來說，對于正常工作日（8小時(shí)）運(yùn)行的系統(tǒng)，至少應(yīng)該能保證系統(tǒng)穩(wěn)定運(yùn)行８小時(shí)以上。對于7*24運(yùn)行的系統(tǒng)，至少應(yīng)該能夠保證系統(tǒng)穩(wěn)定運(yùn)行24小時(shí)以上。
標(biāo)準(zhǔn)
TPS曲線穩(wěn)定，沒有大幅度的波動(dòng)。
各項(xiàng)資源指標(biāo)沒有泄露或異常情況。
?
7）批量處理指標(biāo)：指批量處理程序單位時(shí)間內(nèi)處理的數(shù)據(jù)數(shù)量。一般用每秒處理的數(shù)據(jù)量來衡量。
處理效率是估算批量處理時(shí)間窗口最重要的計(jì)算指標(biāo)。
關(guān)于批量處理時(shí)間窗口，不同系統(tǒng)的批量處理時(shí)間窗口在起止時(shí)間上可以部分重疊。另外，同一系統(tǒng)內(nèi)部，也可能存在多個(gè)批量處理過程同時(shí)進(jìn)行，其時(shí)間窗口相互疊加。
標(biāo)準(zhǔn)
在數(shù)據(jù)量很大的情況下，批處理時(shí)間窗口時(shí)間越短越好。
不能影響實(shí)時(shí)交易系統(tǒng)性能。
?
8）可擴(kuò)展性指標(biāo)：指應(yīng)用軟件或操作系統(tǒng)以群集方式部署，增加的硬件資源與增加的處理能力之間的關(guān)系。
計(jì)算公式為：（增加性能/原始性能）/（增加資源/原始資源）*100%。
擴(kuò)展能力應(yīng)通過多輪測試獲得擴(kuò)展指標(biāo)的變化趨勢。
標(biāo)準(zhǔn)
理想的擴(kuò)展能力是資源增加幾倍，性能就提升幾倍。
擴(kuò)展能力至少在70%以上。
?
9）可靠性指標(biāo)：雙機(jī)熱備、集群、備份和恢復(fù)。
| 指標(biāo) | 測試內(nèi)容 |
| 雙機(jī)熱備 | 節(jié)點(diǎn)切換是否成功及其消耗時(shí)間 雙機(jī)切換是否有業(yè)務(wù)中斷 節(jié)點(diǎn)回切是否成功及其耗時(shí) 雙機(jī)回切是否有業(yè)務(wù)中斷 節(jié)點(diǎn)回切過程中的數(shù)據(jù)丟失量 |
| 集群 | 集群中某個(gè)節(jié)點(diǎn)出現(xiàn)故障時(shí)，系統(tǒng)是否有業(yè)務(wù)中斷情況出現(xiàn) 在集群中新增一個(gè)節(jié)點(diǎn)時(shí)，是否需要重啟系統(tǒng) 當(dāng)故障節(jié)點(diǎn)恢復(fù)后，加入集群，是否需要重啟系統(tǒng) 當(dāng)故障節(jié)點(diǎn)恢復(fù)后，加入集群，系統(tǒng)是否有業(yè)務(wù)中斷情況出現(xiàn) 節(jié)點(diǎn)切換需要多長時(shí)間 |
| 備份和恢復(fù) | 備份是否成功及其消耗時(shí)間 備份是否使用腳本自動(dòng)化完成 恢復(fù)是否成功及其消耗時(shí)間 恢復(fù)是否使用腳本自動(dòng)化完成 |
?
2.?具體性能的分析流程？
首先看關(guān)鍵指標(biāo)是否滿足需求，如果不滿足，需要確定是哪個(gè)地方有問題，一般情況下，服務(wù)器端問題可能性比較大，也有可能是客戶端問題（這種可能性非常小）。
如果是服務(wù)器端的問題，需要定位的問題有硬件相關(guān)指標(biāo)，例如CPU，Memory，Disk I/O，Network I/O，如果是某個(gè)硬件指標(biāo)有問題，需要深入的進(jìn)行分析。如果中間件相關(guān)指標(biāo)沒問題，需要查看數(shù)據(jù)庫相關(guān)指標(biāo)，例如：慢查SQL，命中率，鎖，參數(shù)設(shè)置。
如果以上指標(biāo)都正常，應(yīng)用程序的算法、緩沖、緩存、同步或異步可能有問題，需要具體深入的分析。
?
3.?如果讓你去優(yōu)化前端頁面，你的優(yōu)化流程是？
遇到問題，第一步是確定問題，先要確定是前端的問題還是后端的問題。
如果是前端的問題，那就要確定在哪些地方出了問題，按照前端的各種檢測方法來檢查。
如果是后端的問題，就從系統(tǒng)、中間件、數(shù)據(jù)庫、網(wǎng)絡(luò)等方面入手。
如何確定問題呢？
比如用Firefox的firebug調(diào)試，看一次請求在各部分分別花了多少時(shí)間，哪些請求耗時(shí)最長。
如果請求的是靜態(tài)資源，時(shí)間很長，就需要考慮部署CDN啥的；
如果請求的不是靜態(tài)資源而是服務(wù)器數(shù)據(jù)，時(shí)間長速度慢，那就分兩種情況進(jìn)行考慮：第一是后端的問題，第二是前端渲染問題。
如果返回?cái)?shù)據(jù)很快，但界面數(shù)據(jù)沒出來，就要考慮是前端js程序問題還是圖片等資源太大的問題等等。
轉(zhuǎn)載于:https://www.cnblogs.com/malinalian/p/10583314.html
總結(jié)
以上是生活随笔為你收集整理的性能测试四十五：性能测试策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： VS2010 C++下编译调试Mongo
- 下一篇： common lisp 学习第一天 初步