問題原因找到了，那就好辦了。
找到阿里雲技術人員，讓他們強行給我們上架了一個共享代理模式的RDS。 並重新進行壓力測試。
哦豁~ 開心，壓力測試順利，異常率大大降低實際為：
數據庫DBA反饋，數據庫收到很多請求處理，數據庫開始正常工作。(之前都是，數據庫連接滿，但活躍連接只有1到5個)。 數據庫連接數在50到100之間波動，且基本都是活躍連接。
NGINX和php那邊都工作正常，服務器cpu壓力下降。各項功能都平穩。
然后開始真真正正進行模擬生產用戶數據壓力測試：
生產環境數據如下：
高峰時期： 總並發連接數12w 活躍連接數10萬；新建連接數1300/s；吞吐量：6200/S。
如何通過調整jmeter腳本的線程數，吞吐量來實現該場景，就得多次嘗試了。
jmeter運行環境如下： centos7 java1.8.161； jmeter 5.2.1 4C8G。 阿里雲機器。
1，實現並發連接數和活躍連接數。
並發連接數=活躍連接數+非活躍連接數
活躍連接數=jmeter線程數*執行機器數量
非活躍連接數=tcp連接中斷數： 實際執行過程中發現：如果設置的吞吐量過高，會造成大量的非活躍連接數。與真實請求場景不一致。 后面細說。
如何提升活躍連接數：------加機器+內存。沒其它辦法。現在的機器一般cpu都是夠用的。 實際設置1800線程運行時，機器只有20%的cpu使用率。
通過測試的經驗計算，大概一個線程需要消耗3M內存。所有如果想跑2000線程，那么你得設置虛擬機6000m，否則，會爆出內存溢出錯誤。
通過命令啟動執行機：
JVM_ARGS="-Xms1024m -Xmx6000m" ./jmeter-server & ####注意，不要超過自己機器實際能使用的內存！！！！留點空閑給機器本身用，否則會很卡，很慢。異常高。
我喜歡這種方式，方便調整內存。哈哈。
順便寫幾個清理內存和殺進程的命令：
查看執行機運行日志： tail -f apache-jmeter-5.2.1/bin/jmeter-server.log 查看1099端口： netstat -an|grep 1099 查看java進程： ps -ef|grep java 批量殺進程操作：我特別喜歡哈哈 ps -ef|grep java|awk '{print $2}'|xargs kill -9 統計查詢tcp 80端口數量： netstat -nat|grep -i 80|wc -l 統計查詢tcp time_wait 端口數量： netstat -an | awk '/^tcp/ {++s[$NF]} END {for(a in s) print a,s[a]}'
查看內存使用量：
free -m
同步緩存：
sync
清理內存：建議在殺java進程后使用，先使用sync同步。
echo 3 > /proc/sys/vm/drop_caches
實際運行效果，機器正常跑2000線程正常，不卡，不慢，非常happy~
然后計算10萬用戶=10萬除以2000===50個機器~~~ 汗~~有點難申請。還要加5個調度機、、一共是55個機器~ 1個調度機帶10個執行機。
和大佬凶猛的溝通了一陣子~ 同意了。直接在阿里雲上復制已經調試好jmeter的執行機。刷刷刷刷~~~機器到手了。 反正阿里雲按量收費，用一天也沒多少錢。
如何降低非活躍連接數呢？
由於我設置的tcp連接超時周期為30秒，當我未對吞吐量進行限制時：發現非活躍連接數非常多。 這與生產環境不一致。(該測試結果圖片基於 1帶13執行機，用戶線程1500.當時的吞吐量為12000/s,大大超過實際的需求)
生產環境數據：
仔細琢磨計算了一下。生產10萬活躍用戶，才6200吞吐量，那么。 2萬活躍用戶的吞吐量應該是===1300：
這里發現一個關鍵指標： 新建並發連接數：生產環境高峰期也就1300，而我 6000+；所以，會出現大量的非活躍連接請求就很正常了。
解決辦法：使用jmeter定時器》》精准吞吐量計時器來對吞吐量進行限制。降低新建連接數，降低吞吐量。
通過計算：20000活躍用戶吞吐量1300，那么jmeter腳本2000線程對於吞吐量是130/s。額好低。不忍直視。習慣了幾千幾千上萬的，吞吐量。最后發現只要設置130。
所以：這里有一個結論，真真的性能大神測試時，都不是像我這樣的搞茫茫多機器去跑，一般也就設置100到200線程，進行服務器性能測試。通過性能調優來優化服務器。通過對測試結果日志的分析，來找到服務器問題的。
而不是像我這樣，去想着把服務器搞掛，來復現問題…………
好了，設置好jmeter吞吐量，再進行一波測試。
非活躍連接數大大降低~~達到理想要求。 但還是比較多~ 新建請求連接數1690~ 超過高峰1300. 還需要慢慢優化~
腳本環境都調試完畢，以后，就開始加機器，測試吧~~~
待補充： 等測完了再來補充
過去了一個月，終於有時間來補欠下的債了。。
與運維溝通配置3套壓測機環境，都是1帶14.共組成42個執行機。
單機腳本配置2200用戶。
測試接口共配置51個業務接口，共組成7個業務流程。
測試計划為：
| 業務量類型 |
80% |
100% |
150% |
目的 |
| 並發數 |
9600 |
12000 |
18000 |
分析性能變化趨勢 分析性能問題 幫助定容定量 |
| TPS |
4960 |
6200 |
9300 |
|
| 新建連接數 |
1680 |
2100 |
3250 |
80% 場景結果：
根據圖表數據可以看到;業務系統服務器內存使用40%，cpu使用52%，服務器各個指標穩定。Jmeter請求響應平均響應時間100ms，請求異常數量為0;RDS各項指標也很穩定，主庫從庫連接數，TPS都很正常。請求連接沒有積壓。
100%請求場景：
根據測試結果數據可以看到，業務系統服務器CPU，內存穩定，負載均衡器也很穩定。RDS主庫和從庫都很穩定。
Jmeter 請求有0.05%的異常概率，經過分析，為壓測機器tcp端口耗盡超時導致。不影響服務器性能。
150%性能場景：
當進行150%負載時，服務器cpu達到90%以上，並出現排隊現象。
TPS/QPS穩定在9000左右。 數據RDS連接數增加到100%時的幾倍。請求響應平均時間為400ms。服務器已經滿負荷運行。
使用手機進行打開APP進行體驗：打開頁面緩慢，打開鏈接頁面在3秒左右，但都能正常操作。服務器能正常處理數據，未出現卡死，奔潰。
穩定性測試結果： 持續運行3小時。
測試結果：實際活躍連接數為90000左右，總連接數為155500左右。服務器cpu性能跑滿。RDS壓力不大。持續運行3小時后，系統能正常提供服務，但比較慢。
測試結果總結：
| 參數 |
測試數據 |
||
| 性能指標 |
80% |
100% |
150% |
| ART(ms) |
90 |
100 |
400 |
| TPS |
4900 |
6050 |
9000 |
| CPU |
40.1% |
40.2% |
90% |
| MEM |
40 |
40 |
44 |
| RDS主QPS/TPS |
1811/257 |
1781/303 |
2624/412 |
| RDS讀QPS/TPS |
13195/279 |
12820/289 |
19443/411 |
測試數據已經完成，剩下的就是分析調優了，這個后續再開新章節。
遇到一個新的錯誤： 機器內存耗盡了。自動殺死進程。--調整jvm的內存，減少線程數。保證可用內存大於200M。
