JMeter工具接口性能壓力測試分析與優化

 

最近公司做的項目，要求對相關接口做性能壓力測試，在這里記錄一下分析解決過程。

壓力測試過程中，如果因為資源使用瓶頸等問題引發最直接性能問題是業務交易響應時間偏大，TPS逐漸降低等。而問題定位分析通常情況下，最優先排查的是監控服務器資源利用率，例如先用TOP 或者nmon等查看CPU、內存使用情況，然后在排查IO問題，例如網絡IO、磁盤IO的問題。 如果是磁盤IO問題，一般問題是SQL語法問題、MYSQL參數配置問題、服務器自身硬件瓶頸導致IOPS吞吐率問題。

 

　　一、具體測試結果如下：

A接口、B接口性能壓力測試結果
測試接口	A接口、iB接口
測試工具	JMeter
測試機IP	172.xx.xx.xx，172.xx.xx.xx
軟硬件環境	雙臺Linux操作系統服務器 8核CPU 應用分配4GB內存 500GB硬盤 應用服務器：tomcat（集群） 數據庫：mycat+mysql（讀寫分離）
測試人員	xxx
測試日期	2019/03/18-2019/03/19
測試方案	1.采用階梯式增壓模式，每個階梯壓10min，接口響應時間在3s內 2.並發線程數從30，50，100，200倍數往上增 3.每個事務處理響應時間為100ms
測試需求	1）系統可用性：99.5％； 2）A接口在3s內回應； 3）B接口在3s內回應； 4）服務器支撐業務容量達：40 TPS 以上； 5）服務器的內存、CPU使用率不超過 75%；
結果描述	從如下表格測試數據中可得出： 1.單接口場景下： A接口最優的TPS=76.4；90%Line的響應時間=782ms；當用戶數達 900個/秒以上時，有0.51%請求響應時間有超3s的，會影響用戶體驗； 2.單接口場景下： B接口最優的TPS=138.4；90%Line的響應時間=880ms； 當用戶數達 1000個/秒以上時，有2.51%請求響應時間有超3s的，會影響用戶體驗； 3.混合接口場景下：A+B接口最優的TPS=90.7；90%Line的響應時間=656ms；當用戶數達 1000個/秒以上時，有17.95%請求響應時間有超3s的，會影響用戶體驗；   注:如下結果數據表中，綠色標註為本次測試結果的最優值；  出錯率為響應時間超出3s的錯誤，測試中並未遇到出現程序上的異常問題. 【本輪測試結果】： PASS
場景	用例名稱	並發線程數（：個/秒）	發包總數（：請求數）	出錯率	平均TPS	平均響應時間（：ms）	90%Line(:ms)	被測試服務器CPU利用率	被測試服務器memory
單接口業務	A接口	300	45842	0.00%	76.4	389	782	18%	45%
	A接口	500	46141	0.00%	76.8	645	1327	22%	50%
	A接口	750	44129	0.00%	73.4	1012	2095	21%	50%
	A接口	900	42871	0.51%	71.3	1250	2594	21%	58%
	A接口	1000	41882	9.56%	69.7	1422	2993	30%	55%
單接口業務	B接口	500	83145	0.00%	138.4	358	880	30%	60%
	B接口	700	56325	0.03%	93.8	739	1523	20%	50%
	B接口	1000	57421	2.51%	95.5	1037	2502	15%	43%
混合接口業務	A+B接口	300	54442	0.00%	90.7	327	656	21%	56%
	A+B接口	500	53068	0.00%	88.4	560	1218	25%	60%
	A+B接口	700	49808	0.42%	82.9	836	1878	25%	55%
	A+B接口	1000	93104	17.95%	61.9	959	3001	55%	50%

 

 

　　二、初始應用配置調整：

　　　　1、調整nginx的連接數為65535；

　　　　　　events {
　　　　　　　　use epoll;
　　　　　　　　worker_connections 65535;
　　　　　　}

　　　　2、調整tomcat的最大 線程數為300，默認為200；

　　　　　  調整a ccept隊列的長度為500，默認為100；

　　　　　  因為使用的是tomcat7版本，默認使用的是BIO，調整為 NIO模式

　　　　　　<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
　　　　　　　　connectionTimeout="60000"
　　　　　　　　maxThreads="300"
　　　　　　　　acceptCount="500"
　　　　　　　　URIEncoding="UTF-8"
　　　　　　　　useBodyEncodingForURI="true"
　　　　　　　　enableLookups="false"
　　　　　　　　redirectPort="8443" />

 

　　　　3、根據服務器內存情況，調整tomcat堆內存及垃圾回收器，這里分配4G（機器有8G），因為這台機器上部署了2個應用；

　　　　4、在tomcat配置中（bin/catalina.sh），開啟jmc遠程監控端口

　　　　　　JAVA_OPTS="-server -Dfile.encoding=UTF-8 -Xms4g -Xmx4g -Xmn2g -Xss512K -verbose:gc -XX:+UseConcMarkSweepGC
　　　　　　　　　　-XX:MaxTenuringThreshold=10 -XX:PermSize=512m -XX:MaxPermSize=1g -XX:+ExplicitGCInvokesConcurrent -XX:GCTimeRatio=19
　　　　　　　　　　-XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=10
　　　　　　　　　　-XX:+CMSClassUnloadingEnabled -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=50
　　　　　　　　　　-Xnoclassgc -XX:SoftRefLRUPolicyMSPerMB=0
　　　　　　　　　　-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9433
　　　　　　　　　　-Djava.rmi.server.hostname=172.xx.xx.xx 
　　　　　　　　　　-Dcom.sun.management.jmxremote.ssl=false
　　　　　　　　　　-Dcom.sun.management.jmxremote.authenticate=false"

 

　　三、分析解決過程： 

　　　　剛開始測試的時候，TPS上不去，只有30幾：

 

　　然后進行以下分析：

　　1、檢查【應用cpu】使用情況，只有3%左右，cpu沒用充分使用起來；

　　2、檢查【應用堆內存】使用情況，只使用了500M（實際分配了4G），內在也沒有充分使用起來；

以上2項指標，可以通過jdk自帶的visualVM工具查看：

　　

　　3、查看慢sql，發現慢的SQL也沒有，因為使用了Druid Monitor組件，可以使用它來分析

　　　　http://172.xx.xx.xx:8089/xxx/druid/sql.html

 

　　4、查看mycat日志是否已滿，發現也沒滿。空間監控df -h ，防止文件系統空間滿造成數據庫hang住

　　　　

 

　　5、查看數據庫磁盤io，發現比較低，只有10幾%；

　　　　iostat -x 中 r/s w/s svctm<=6ms %util<80%

　　　　

 

 

　　6、最后分析JMeter工具中的壓測結果，發現有很多響應時間超過3s以上的，在應用日志中找到這些記錄，分析調用鏈路（分布式系統）各個節點的耗時，發現有個應用中使用了synchronized鎖，在高並發情況下獲取鎖耗時3s以上；

　　　　

 

　　7、修復程序，重新壓測，tps就達到了80左右，耗時多的記錄也基本上沒有了，至此，此次性能壓力測試已結束。

 

注意：重復壓測，會發現隨着壓測的次數增多，TPS會越來越低。那是因為應用中的日志會越來越大，導致寫入時hand住了，要刪除日志文件。

 

 　四、mysql性能監控指標： 

　　在分析過程中，在網上查了不少資料，在這里也簡單描述一下：

    1、os層面
        空間監控df -h ，防止文件系統空間滿造成數據庫hang住
        性能cpu監控
            vmstat 
                r隊列，這個隊列需要小於cpu核數，最大不要超過4倍？？？
            top load average隊列數量，同上？？？
            top中sys cpu占比小於5%，iowait占比小於5%，user占比小於70%
            top H線程占cpu占比，不要出現70%+的線程

    2、內存
        vmstat中出現swap in out    ，free至少2G以上

    3、io
        iostat -x 中  r/s     w/s 
        svctm<=6ms
        %util<80%

    4、網絡監控
        sar監控中，網絡帶寬不需要達到90%，一般1000Mbit/s 帶寬足夠使用，除了備份等場景

    5、數據庫
        真實負載監控

　　 6、監控工具
　　　　　　ZABBIX