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

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

1 接口名稱: 獲取列表

1.1 壓測現(xiàn)象:單臺tps700多，應(yīng)用cpu高負載

　　1.1.1 問題分析:

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

　　1.1.2 改進措施:

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

　　1.1.3 改進效果:

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

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

　　1.2.1 問題分析:

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

　　1.2.2 改進措施:

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

　　1.2.3 改進效果:

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

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

　　1.3.1 問題分析:

　　　　后端都是15臺tomcat，前端1臺nginx時tps為4552,通過lvs掛10臺nginx時為9608，增長不明顯，其nginx和tomcat都壓力不大，集群結(jié)果不合理，懷疑是nginx轉(zhuǎn)發(fā)配置的問題；

　　1.3.2 改進措施:

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

　　1.3.3 改進效果:

2 接口名稱: 信息查詢接口

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

　　2.1.1 問題分析:

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

　　2.1.2 改進措施:

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

　　2.1.3 改進效果:

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

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

　　2.2.1 問題分析:

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

　　2.2.2 改進措施:

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

　　2.2.3 改進效果:

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

3 接口名稱: 獲取詳情

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

　　3.1.1 問題分析:

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

　　3.1.2 改進措施:

　　　　開啟tomcat的gzip壓縮。

　　3.1.3 改進效果:

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

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

　　3.2.1 問題分析:

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

　　3.2.2 改進措施:

　　　　優(yōu)化nginx：

　　　　l nginx日志關(guān)閉

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

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

　　3.2.3 改進效果:

　　Tps由10022提升為13270。

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

　　3.1.1 問題分析:

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

　　3.1.2 改進措施:

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

　　3.1.3 改進效果:

4 接口名稱: 促銷

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

　　4.1.1 問題分析:

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

　　4.1.2 改進措施:

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

　　4.1.3 改進效果:

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

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

　　4.1.1 問題分析:

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

　　4.1.2 改進措施:

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

　　4.1.3 改進效果:

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

4.2 壓測現(xiàn)象:1N3T tps1萬多，在增大tomcat可能tps增長不會明顯

　　4.2.1 問題分析:

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

　　4.2.2 改進措施:

　　　　可以增加多臺nginx負載，前端加lvs

　　4.2.3 改進效果:

5 接口名稱: 追蹤接口

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

　　5.1.1 問題分析:

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

　　5.1.2 改進措施:

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

　　5.1.3 改進效果:

6 接口名稱: 回填接口

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

　　6.1.1 問題分析:

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

　　6.1.2 改進措施:

　　　　1.連接池由dbcp改為hikar；

　　　　2.減少了日志打印輸出

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

　　6.1.3 改進效果:

　　Tps由不到500增長為1300多。

7 接口名稱: 券查詢

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

　　7.1.1 問題分析:

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

　　7.1.2 改進措施:

　　　　可以考慮分庫

　　7.1.3 改進效果:

8 接口名稱: 推薦

8.1 壓測現(xiàn)象:nginx長短連接差異

　　8.1.1 問題分析:

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

　　8.1.2 改進措施:

　　　　將nginx改為長連接

　　8.1.3 改進效果:

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

9 接口名稱: 查詢2

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

　　9.1.1 問題分析:

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

　　9.1.2 改進措施:

　　　　將日志級別由debug級改為info級

　　9.1.3 改進效果:

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

總結(jié)

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

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