性能測(cè)試分析與使用

一.為什么要做性能測(cè)試?

xx系統(tǒng)已經(jīng)成功發(fā)布，依據(jù)之前項(xiàng)目的規(guī)劃，計(jì)劃服務(wù)1000+客戶,未來勢(shì)必會(huì)出現(xiàn)業(yè)務(wù)系統(tǒng)中信息大量增長(zhǎng)的趨勢(shì)。
隨著該系統(tǒng)在生產(chǎn)狀態(tài)下日趨穩(wěn)定，也讓我們可以更靜下心來去關(guān)注性能方面的問題：

1. 能夠承受多大的數(shù)據(jù)量？

2. 系統(tǒng)的瓶頸是什么？

3. 代碼的質(zhì)量怎么樣？

   這些問題都需要通過性能測(cè)試來給出答案

二.需要注意什么?

1.明確測(cè)試目的

性能測(cè)試的目的分為兩種：

• 驗(yàn)證：驗(yàn)證系統(tǒng)是否符合相關(guān)的性能需求。 如:滿足500人的并發(fā)請(qǐng)求

• 定位調(diào)優(yōu)：通過測(cè)試獲取相關(guān)數(shù)據(jù)，針對(duì)數(shù)據(jù)進(jìn)行分析、定位、調(diào)優(yōu)。

2.確定測(cè)試內(nèi)容

• 明確業(yè)務(wù)點(diǎn)與優(yōu)先級(jí)

• 要根據(jù)功能、性能的優(yōu)先級(jí)去劃分業(yè)務(wù)的優(yōu)先級(jí)別，確定待測(cè)和不測(cè)業(yè)務(wù)

• 針對(duì)不同的業(yè)務(wù)和場(chǎng)景確定相關(guān)的性能需求:吞吐量、響應(yīng)時(shí)間等。

3.了解性能測(cè)試類別

1. 網(wǎng)絡(luò)級(jí)別的測(cè)試 當(dāng)前測(cè)試

   吞吐量和響應(yīng)時(shí)間

2. 操作系統(tǒng)的測(cè)試

   cpu利用率, 磁盤交換率

3. 數(shù)據(jù)庫級(jí)別的測(cè)試

   數(shù)據(jù)庫并發(fā)連接數(shù) ,鎖資源的使用數(shù), I/O的流量大小

4.受影響的因素

1. 網(wǎng)絡(luò)帶寬 如：阿里50M 100M

2. 服務(wù)器數(shù)量 如：阿里云服務(wù)器

3. 服務(wù)器CPU,內(nèi)存等性能 如：阿里的 2G 8G 固態(tài)硬盤,機(jī)械硬盤

4. 服務(wù)器操作系統(tǒng)版本

5. 代碼質(zhì)量

三.基本使用操作

Jmeter使用文檔在線地址: [https://blog.csdn.net/r657225738/article/details/114981779]{.underline}

1. 簡(jiǎn)單的http請(qǐng)求

2. 自定義用戶變量

3. 提取請(qǐng)求數(shù)據(jù),并存入文件中

場(chǎng)景: 批量新增,批量查詢
所需組件: [正則表達(dá)式提取器->BeanShell 后置處理程序] 注意點(diǎn):
文字編碼: utf-8

4. 使用CSV文件,讀取數(shù)據(jù)

場(chǎng)景: 批量編輯,批量刪除

所需組件: [CSV 數(shù)據(jù)文件設(shè)置]

四.用數(shù)據(jù)說話

1.代碼優(yōu)化前后對(duì)比

問題列表-我的問題

2.單雙副本的性能差距

五.經(jīng)驗(yàn)總結(jié)

1.代碼優(yōu)化思路

通過APM鏈路跟蹤 查看API的操作日志

• 1.減少不必要的訪庫操作

  2.減少不必要的數(shù)據(jù)調(diào)用

例: 問題列表-我的問題 更新前與更新后

通過測(cè)試和代碼調(diào)優(yōu),有兩點(diǎn)需要大家注意

• 1.測(cè)試工具: Jemter進(jìn)行并發(fā)測(cè)試

  2.問題定位: 具體API通過內(nèi)網(wǎng)APM鏈路跟蹤來找到優(yōu)化代碼方向

得出結(jié)果:

1. 并發(fā)測(cè)試中,API異步會(huì)直接提升性能.未寫異步的API 20個(gè)并發(fā), 吞吐量可能低至個(gè)位數(shù). API改為Task異步 之后,100個(gè)并發(fā), 吞吐量能到150-200

2. 去掉代碼中不必要的API訪問可繼續(xù)提升性能, 性能 提升明顯. (和去掉的無關(guān)API訪問數(shù)量有關(guān)) 測(cè)試 中,100個(gè)并發(fā),吞吐量能到200-250

2.性能測(cè)試時(shí)API報(bào)錯(cuò)解答

在保證API地址與參數(shù)填寫正確的情況下,如還報(bào)錯(cuò)則為以下兩種情況

1. API報(bào)500

1.1數(shù)據(jù)庫崩潰,卡死,需要重啟

2. API報(bào)404

2.1所在企業(yè)Api服務(wù)卡死,需要重啟

六.小知識(shí)

6.1聚合報(bào)告中的參數(shù)含義

• 最小值:指請(qǐng)求到服務(wù)器后返回?cái)?shù)據(jù)所需最少時(shí)間

• 最大值:指請(qǐng)求到服務(wù)器后返回?cái)?shù)據(jù)所需最多時(shí)間

• 異常值:指請(qǐng)求會(huì)出現(xiàn)斷開或連接異常的比例

• TPS(吞吐量):指每秒可處理多少請(qǐng)求,如120/sec,即每秒可處理120個(gè)網(wǎng)絡(luò)請(qǐng)求. 20/min,即每分鐘

• 平均值:指所有請(qǐng)求響應(yīng)時(shí)間總和的平均值

• 99%:指有99%的請(qǐng)求在此范圍之下,如354ms / 99%,即有99%的請(qǐng)求在354ms之前就完成了響應(yīng)

6.2增加Replicated(副本) /Scale(規(guī)模)的作用

1.自己理解: Docker會(huì)在發(fā)生故障時(shí)花費(fèi)更少的時(shí)間在另一個(gè)節(jié)點(diǎn)上創(chuàng)建新實(shí)例，這有助于提高性能,減少故障率.如目前有三個(gè)副本(replicated)，當(dāng)其中一個(gè)副本（服務(wù)器）承受不住時(shí)，會(huì)自動(dòng)轉(zhuǎn)移至可用的副本上。

2.專業(yè)解釋: 讓我們以包含單個(gè)實(shí)例的副本為例?，F(xiàn)在，假設(shè)有一個(gè)失敗。Docker Swarm將注意到該服務(wù)失敗并重新啟動(dòng)它。該服務(wù)將重新啟動(dòng)，但是重新啟動(dòng)不是即時(shí)的。假設(shè)重新啟動(dòng)需要5秒鐘。在這5秒鐘內(nèi)，您的服務(wù)不可用。單點(diǎn)故障。

如果您的副本包含3個(gè)實(shí)例怎么辦?，F(xiàn)在，當(dāng)其中一個(gè)發(fā)生故障（沒有完美的服務(wù)）時(shí)，Docker Swarm將注意到其中一個(gè)實(shí)例不可用，并創(chuàng)建一個(gè)新實(shí)例。在這段時(shí)間內(nèi)，您仍然有2個(gè)運(yùn)行正常的實(shí)例來處理請(qǐng)求。對(duì)于您的服務(wù)的用戶，似乎沒有停機(jī)時(shí)間。該組件不再是單點(diǎn)故障。

6.3 Scale調(diào)度規(guī)則

將node1宕機(jī)后或?qū)ode1的docker服務(wù)關(guān)閉，那么它上面的task實(shí)例就會(huì)轉(zhuǎn)移到別的節(jié)點(diǎn)上。當(dāng)node1節(jié)點(diǎn)恢復(fù)后，它轉(zhuǎn)移出去的task實(shí)例不會(huì)主動(dòng)轉(zhuǎn)移回來，只能等別的節(jié)點(diǎn)出現(xiàn)故障后轉(zhuǎn)移task實(shí)例到它的上面。使用命令\"docker node ls\"，發(fā)現(xiàn)node1節(jié)點(diǎn)已不在swarm集群中了。

6.4 高并發(fā)的通俗含義

打個(gè)比方說，好比你開小吃店。

你有3個(gè)收銀（web請(qǐng)求處理線程），5個(gè)廚師（數(shù)據(jù)庫連接）。

一開始，生意沒開多久。客人比較少。1個(gè)收銀都能搞定。另外的人還閑著。

后來生意越來越好。于是得3個(gè)收銀都干活（并發(fā)）。

結(jié)果過了一段時(shí)間來了個(gè)網(wǎng)紅，突然店就火了，一大群人（高并發(fā)）慕名而來。

結(jié)果3個(gè)收銀跟前大牌長(zhǎng)龍（請(qǐng)求阻塞排隊(duì)），而且收銀也不是機(jī)器人，有的時(shí)候也會(huì)搞錯(cuò)單子（并發(fā)異常）。

再看后面廚師，單子越來越多，廚師一直做菜一直做菜，越來越來累，就越做越慢（數(shù)據(jù)庫壓力大，請(qǐng)求響應(yīng)時(shí)間變長(zhǎng)）。

菜出得越慢，后面排隊(duì)的人就越多（請(qǐng)求阻塞后惡性循環(huán)）。

有的客人等不及了就直接走了（服務(wù)超時(shí)），順手還給了你一個(gè)差評(píng)，影響自身的心情（影響上層服務(wù)）。

而后面的廚師呢，做了N道菜之后終于扛不住了，再也做不動(dòng)了（數(shù)據(jù)庫連接耗盡）。

于是乎小店只能暫停接客（服務(wù)器拒絕請(qǐng)求，報(bào)錯(cuò)502）。

6.5吞吐率和并發(fā)數(shù)通俗意思

案例一: 吞吐率和并發(fā)數(shù)是兩個(gè)完全獨(dú)立的概念。拿銀行柜臺(tái)來舉個(gè)例子，并發(fā)數(shù)指同時(shí)有多少人往銀行柜臺(tái)涌來。吞吐率則指銀行柜臺(tái)在一段時(shí)間內(nèi)可以服務(wù)多少個(gè)人

案例二: 一個(gè)水龍頭開一天一夜，流出10噸水；10個(gè)水龍頭開1秒鐘，流出0.1噸水。當(dāng)然是一個(gè)水龍頭的吞吐量大。你能說1個(gè)水龍頭的出水能力比10個(gè)水龍頭的強(qiáng)？所以，我們要加單位時(shí)間，看誰1秒鐘的出水量大。這就是吞吐率 0.1噸水/秒
，報(bào)錯(cuò)502）。文章來源地址http://www.zghlxwxcb.cn/news/detail-400612.html

到了這里，關(guān)于性能測(cè)試分析與使用的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！