互聯(lián)網(wǎng)常見(jiàn)架構(gòu)接口壓測(cè)性能分析及調(diào)優(yōu)手段建議

常見(jiàn)的互聯(lián)網(wǎng)架構(gòu)中，一般都能看到spring+mybatis+mysql+redis搭配的身影，在我所服務(wù)的公司亦是如此。一般來(lái)說(shuō)，應(yīng)用內(nèi)部的接口都是直接調(diào)用的，所謂的面向接口編程，應(yīng)用間的調(diào)用直接調(diào)或者通過(guò)類(lèi)似dubbo之類(lèi)的服務(wù)框架來(lái)執(zhí)行，數(shù)據(jù)格式往往采用json，即統(tǒng)一也方便各數(shù)據(jù)間做轉(zhuǎn)換和取值，緩存一般使用redis或memcached，存儲(chǔ)一些對(duì)象或json格式的字符串。對(duì)外提供的接口，一般都需要進(jìn)行壓力測(cè)試，以便估算其性能，并為后續(xù)的調(diào)優(yōu)提供指導(dǎo)方向，以下接口便是在壓測(cè)過(guò)程中出現(xiàn)的各種“奇怪現(xiàn)象”，所謂奇怪，指的是從表象上看與我們正常的邏輯思路不符，但其本質(zhì)還是我們對(duì)壓力下程序的表現(xiàn)出來(lái)的特征不熟悉，用慣用的知識(shí)結(jié)構(gòu)試圖去解釋?zhuān)@根本是行不通的。下文是我在一次全面壓測(cè)過(guò)程后對(duì)數(shù)據(jù)進(jìn)行的分析匯總，其中的現(xiàn)象是很多壓測(cè)常見(jiàn)的，里面的分析過(guò)程及改進(jìn)措施我認(rèn)為有很大的參考意義。具體內(nèi)容如下：（部分接口為了安全我省略了其名稱(chēng)，但不影響我們的分析，另外形如1N3T之類(lèi)的表示的是1臺(tái)nginx，3臺(tái)tomcat,具體的tps數(shù)值只是為了說(shuō)明優(yōu)化前后的比照，沒(méi)有實(shí)際意義）

1 接口名稱(chēng): 獲取列表

1.1 壓測(cè)現(xiàn)象:單臺(tái)tps700多，應(yīng)用cpu高負(fù)載

　　1.1.1 問(wèn)題分析:

　　　　舊框架，平均響應(yīng)時(shí)間長(zhǎng)，應(yīng)用CPU高，程序內(nèi)部有大量的bean到map到j(luò)son之間的轉(zhuǎn)換，修改數(shù)據(jù)庫(kù)連接數(shù)后，tps沒(méi)有提升。

　　1.1.2 改進(jìn)措施:

　　　　重構(gòu)系統(tǒng)，用mybatis替代之前的dao操作，減少bean-map-json之間的內(nèi)部數(shù)據(jù)轉(zhuǎn)換，減少程序內(nèi)部的無(wú)用操作。

　　1.1.3 改進(jìn)效果:

　　　　tps改進(jìn)后能到3000左右，有較大提升，但壓測(cè)時(shí)應(yīng)用cpu幾乎跑滿(mǎn)，還有改善空間。

1.2 壓測(cè)現(xiàn)象：數(shù)據(jù)庫(kù)資源利用率高

　　1.2.1 問(wèn)題分析:

　　　　單臺(tái)應(yīng)用，數(shù)據(jù)庫(kù)資源cpu都能到50%，10臺(tái)tomcat在1萬(wàn)并發(fā)下數(shù)據(jù)庫(kù)cpu跑滿(mǎn)，load值700多，但db的qps也不過(guò)11554，并不算多，因此懷疑是sql執(zhí)行耗費(fèi)了cpu，可能是某條sql沒(méi)有按索引查找或者索引失效。

　　1.2.2 改進(jìn)措施:

　　　　查看SQL文件發(fā)現(xiàn)如下sql：select count(1) from orders where order_status_id !=40 ，將其改為select order_id from orders 然后通過(guò)程序把order_status_id!=40的過(guò)濾掉。通過(guò)list.size()來(lái)獲取。order_status_id即使加了索引，由于是！=比較，所以不會(huì)去按索引查找，導(dǎo)致cpu高

　　1.2.3 改進(jìn)效果:

　　　　相同環(huán)境下(1臺(tái)nginx，10臺(tái)tomcat，1000并發(fā))，tps由3000變成3727，略有增長(zhǎng)，但是db的cpu明顯下降，變?yōu)?0%，效果明顯

1.3 壓測(cè)現(xiàn)象:1N15T ,tps4552;10N15T,tps9608

　　1.3.1 問(wèn)題分析:

　　　　后端都是15臺(tái)tomcat，前端1臺(tái)nginx時(shí)tps為4552,通過(guò)lvs掛10臺(tái)nginx時(shí)為9608，增長(zhǎng)不明顯，其nginx和tomcat都?jí)毫Σ淮螅航Y(jié)果不合理，懷疑是nginx轉(zhuǎn)發(fā)配置的問(wèn)題；

　　1.3.2 改進(jìn)措施:

　　　　未進(jìn)一步改進(jìn)：可能是需要調(diào)整nginx的參數(shù)，之前發(fā)現(xiàn)過(guò)nginx不同的配置對(duì)后端集群環(huán)境的tps影響很大

　　1.3.3 改進(jìn)效果:

2 接口名稱(chēng): 信息查詢(xún)接口

2.1 壓測(cè)現(xiàn)象:單臺(tái)tps2000多，應(yīng)用cpu高，db的qps15000左右

　　2.1.1 問(wèn)題分析:

　　　　舊框架，程序內(nèi)部有很多Bo-map-json相互的轉(zhuǎn)換

　　2.1.2 改進(jìn)措施:

　　　　刪除冗余代碼、更換連接池包，使用mybatis

　　2.1.3 改進(jìn)效果:

　　　　Tps由2000多增長(zhǎng)為8000多，db的qps為9000左右，優(yōu)化后壓測(cè)應(yīng)用的cpu占用高，幾乎跑滿(mǎn)。

2.2 壓測(cè)現(xiàn)象：數(shù)據(jù)庫(kù)無(wú)壓力，應(yīng)用增加多臺(tái)后tps不變

　　2.2.1 問(wèn)題分析:

　　　　1N1T和1N10T的tps一樣，都為5000，增大并發(fā)時(shí)錯(cuò)誤數(shù)增多，應(yīng)用cpu耗費(fèi)70%，db無(wú)壓力，nginx單臺(tái)通過(guò)ss –s 發(fā)現(xiàn)端口占滿(mǎn)，即nginx到tomcat之間轉(zhuǎn)發(fā)的連接端口time-wait狀態(tài)6萬(wàn)多。Nginx存在瓶頸。

　　2.2.2 改進(jìn)措施:

　　　　調(diào)優(yōu)nginx參數(shù)，將短連接改為長(zhǎng)連接

　　2.2.3 改進(jìn)效果:

　　　　1N3T的tps能到17376，tomat的cpu壓力84%，db的qps18000，cpu69%，應(yīng)用的資源基本使用到量。

3 接口名稱(chēng): 獲取詳情

3.1 壓測(cè)現(xiàn)象:單臺(tái)應(yīng)用tps2600，10臺(tái)tomcat才3700

　　3.1.1 問(wèn)題分析:

　　增加應(yīng)用服務(wù)器，tps增長(zhǎng)不明顯，且nginx、tomcat、db的負(fù)載都不高，說(shuō)明服務(wù)器本身不是瓶頸，考慮是不是網(wǎng)絡(luò)的問(wèn)題，通過(guò)監(jiān)控網(wǎng)卡包流量發(fā)現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)跑滿(mǎn)，因?yàn)榇私涌跁?huì)有大量數(shù)據(jù)的輸出，因此瓶頸在網(wǎng)絡(luò)上。另外，測(cè)試過(guò)程中發(fā)現(xiàn)redis有報(bào)錯(cuò)，redis服務(wù)器是虛機(jī)，可能服務(wù)能力有限。

　　3.1.2 改進(jìn)措施:

　　　　開(kāi)啟tomcat的gzip壓縮。

　　3.1.3 改進(jìn)效果:

　　　　同等并發(fā)下(1臺(tái)nginx，10臺(tái)tomcat，1000并發(fā))，tps由3727增長(zhǎng)到10022，增長(zhǎng)了近3倍，效果顯著。

3.2 壓測(cè)現(xiàn)象:1N10T集群下nginx參數(shù)調(diào)優(yōu)對(duì)tps提升效果明顯

　　3.2.1 問(wèn)題分析:

　　　　經(jīng)過(guò)tomcat的啟用gzip后，1N10T下tps為10022，需進(jìn)一步提升。

　　3.2.2 改進(jìn)措施:

　　　　優(yōu)化nginx：

　　　　l nginx日志關(guān)閉

　　　　l nginx進(jìn)程數(shù)量worker，由24改為16

　　　　l nginx keepalive數(shù)量由256改為2048

　　3.2.3 改進(jìn)效果:

　　Tps由10022提升為13270。

3.1 壓測(cè)現(xiàn)象:1N5T和1N10T的tps相差不大

　　3.1.1 問(wèn)題分析:

　　　　1N10T的tps為1萬(wàn)3千多，1N5T的tps為1萬(wàn)2千多，相差不大，應(yīng)用的tomcat資源利用沒(méi)滿(mǎn)，cpu為65%，Db的QPS已經(jīng)到2萬(wàn)多了，單臺(tái)服務(wù)器db基本上到量了，因此再增加應(yīng)用也沒(méi)效果，只會(huì)導(dǎo)致響應(yīng)的時(shí)間變長(zhǎng)。

　　3.1.2 改進(jìn)措施:

　　　　單臺(tái)db已經(jīng)無(wú)法改進(jìn)了，要不提升服務(wù)器硬件，要不讀寫(xiě)分離。

　　3.1.3 改進(jìn)效果:

4 接口名稱(chēng): 促銷(xiāo)

4.1 壓測(cè)現(xiàn)象:通過(guò)redis存取數(shù)據(jù)，tps才1000多，CPU 有壓力

　　4.1.1 問(wèn)題分析:

　　　　此接口通過(guò)redis取數(shù)據(jù)，tps不高才1000多，但cpu占用了80%，說(shuō)明程序內(nèi)部有大量序列化反序列化的操作，可能是json序列化的問(wèn)題。

　　4.1.2 改進(jìn)措施:

　　　　將net.sf.json改成alibaba的fastjson。

　　4.1.3 改進(jìn)效果:

　　　　同等并發(fā)條件下tps由1000多提升為5000多，提高了近5倍。

4.1 壓測(cè)現(xiàn)象:參數(shù)多時(shí)tps下降明顯

　　4.1.1 問(wèn)題分析:

　　　　此接口根據(jù)參數(shù)從redis中獲取數(shù)據(jù)，每個(gè)參數(shù)與redis交互一次，當(dāng)一組參數(shù)時(shí)tps5133，五組參數(shù)時(shí)tps1169，多次交互影響了處理性能。

　　4.1.2 改進(jìn)措施:

　　　　將從redis獲取數(shù)據(jù)的get改為mget，減少交互次數(shù)。

　　4.1.3 改進(jìn)效果:

　　　　五組參數(shù)時(shí)1N3T壓測(cè)TPS9707，據(jù)此估算即使是單臺(tái)tomcat，tps也能有三四千，性能比單次get的調(diào)用方式提升了3,4倍。

4.2 壓測(cè)現(xiàn)象:1N3T tps1萬(wàn)多，在增大tomcat可能tps增長(zhǎng)不會(huì)明顯

　　4.2.1 問(wèn)題分析:

　　　　此處說(shuō)的是可能，因?yàn)閚ginx服務(wù)器的cpu雖然不高，但pps已經(jīng)800多k，此時(shí)應(yīng)該是nginx的服務(wù)器網(wǎng)絡(luò)流量成為了瓶頸。(只是猜測(cè))

　　4.2.2 改進(jìn)措施:

　　　　可以增加多臺(tái)nginx負(fù)載，前端加lvs

　　4.2.3 改進(jìn)效果:

5 接口名稱(chēng): 追蹤接口

5.1 壓測(cè)現(xiàn)象:1N10T的tps低于1N3T的tps

　　5.1.1 問(wèn)題分析:

　　　　1N3T在2000并發(fā)下tps為9849，此時(shí)db的qps為90000，CPU80%，將tomcat增到10臺(tái)，5000并發(fā)下,tps為7813，db的qps為19000，cpu75%，load 1，說(shuō)明壓力增大情況下db的壓力反而下來(lái)了，注意到nginx服務(wù)器的網(wǎng)卡流量達(dá)到885M，說(shuō)明是壓力過(guò)大情況下，網(wǎng)絡(luò)滿(mǎn)了，發(fā)生丟包，導(dǎo)致db端壓力反而下來(lái)了。

　　5.1.2 改進(jìn)措施:

　　　　注意壓測(cè)情況下部分接口由于數(shù)據(jù)量傳輸較大，會(huì)出現(xiàn)網(wǎng)絡(luò)瓶頸。

　　5.1.3 改進(jìn)效果:

6 接口名稱(chēng): 回填接口

6.1 壓測(cè)現(xiàn)象:tps不到500，db的qps3500

　　6.1.1 問(wèn)題分析:

　　　　雖然缺少應(yīng)用的cpu及db的cpu利用率數(shù)據(jù)，較低的tps應(yīng)該是應(yīng)用的瓶頸，且需要關(guān)注是不是db在處理查詢(xún)的時(shí)候緩慢。

　　6.1.2 改進(jìn)措施:

　　　　1.連接池由dbcp改為hikar；

　　　　2.減少了日志打印輸出

　　　　3.sql優(yōu)化，將部分條件過(guò)濾改為在java代碼中執(zhí)行

　　6.1.3 改進(jìn)效果:

　　Tps由不到500增長(zhǎng)為1300多。

7 接口名稱(chēng): 券查詢(xún)

7.1 壓測(cè)現(xiàn)象:集群結(jié)果與單臺(tái)應(yīng)用結(jié)果相比不合理

　　7.1.1 問(wèn)題分析:

　　　　查看是否存在瓶頸資源，可以看到5臺(tái)tomcat集群下，tps為9952，但db的qps為5-6萬(wàn)，cpu利用率為37%，說(shuō)明對(duì)數(shù)據(jù)庫(kù)進(jìn)行了大量的主鍵或索引查詢(xún)，一般單臺(tái)db的qps也就4萬(wàn)左右，再增加應(yīng)用的集群數(shù)量，對(duì)tps也不會(huì)有太大影響。

　　7.1.2 改進(jìn)措施:

　　　　可以考慮分庫(kù)

　　7.1.3 改進(jìn)效果:

8 接口名稱(chēng): 推薦

8.1 壓測(cè)現(xiàn)象:nginx長(zhǎng)短連接差異

　　8.1.1 問(wèn)題分析:

　　　　18nginx，2tomcat時(shí)tps8100，此時(shí)應(yīng)用服務(wù)器的端口數(shù)滿(mǎn)， 一般來(lái)說(shuō)，Nginx短連接在高并發(fā)下容易導(dǎo)致端口占滿(mǎn)的問(wèn)題。

　　8.1.2 改進(jìn)措施:

　　　　將nginx改為長(zhǎng)連接

　　8.1.3 改進(jìn)效果:

　　　　tps增長(zhǎng)為10733，TPS穩(wěn)定，起伏減少，但是CPU耗盡。說(shuō)明cpu打滿(mǎn)了，此時(shí)如果還要優(yōu)化就的進(jìn)行代碼調(diào)優(yōu)了。

9 接口名稱(chēng): 查詢(xún)2

9.1 壓測(cè)現(xiàn)象:18N20T的tps才6842

　　9.1.1 問(wèn)題分析:

　　　　18臺(tái)nginx，20臺(tái)tomcat，tps才6842，此時(shí)應(yīng)用cpu利用率85%，說(shuō)明cpu存在瓶頸，但檢查此接口并未做大計(jì)算量的工作，有可能是日志的級(jí)別問(wèn)題，cpu在頻繁的打日志。

　　9.1.2 改進(jìn)措施:

　　　　將日志級(jí)別由debug級(jí)改為info級(jí)

　　9.1.3 改進(jìn)效果:

　　　　同等環(huán)境tps由6842增長(zhǎng)為23592.坑爹的生產(chǎn)環(huán)境debug日志級(jí)別。

總結(jié)

以上是生活随笔為你收集整理的压力测试常见问题总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。