優(yōu)化前后對比
優(yōu)化前tp99和服務(wù)器資源
優(yōu)化后tp99和服務(wù)器資源
問題的具體排查
優(yōu)化思路、硬件的負載、tomcat的使用情況分析
http://m.itdecent.cn/p/8e032ff74501
問題1：去除額外的線上切換
源代碼值使用了thenAcceptAsync，在線程執(zhí)行完后切換線程，交給另一個線程執(zhí)行賦值?？梢钥吹较鄬唵?，但是多了一次線程切換的額外開銷
將賦值部分直接加入原操作，減少了一次額外的線程開銷。
問題2：過多的線程帶來的額外開銷
首先明確一個事情，線程越多不代表接口耗時就會越低，反而可能是一種負擔，線上的上下文切換是會有內(nèi)存和CPU消耗的。
通過ARMS可知，閑置的線程過多，明顯存在浪費的情況。降了了線程池的數(shù)量，使用率其實還是在地位，為了應(yīng)對突發(fā)流量（QPS可能從15萬直接翻倍到30萬）預(yù)留的線程數(shù)相對較高
問題3：降低redis連接的開銷
過多的線程池連接會不僅僅會浪費資源，還是間接的升高TP99，所以不要過多
java配置*節(jié)點數(shù)=真實的連接數(shù)量
問題4：阿里云LB的限制
這個沒有具體的截圖，阿里的LB有個限制， 每個LB能掛在的節(jié)點數(shù)量是300個.
而這個服務(wù)額外給監(jiān)控開了個端口占用了XXX個節(jié)點，當時發(fā)現(xiàn)的時候占用了120個，真實給到服務(wù)的節(jié)點其實只有180個，釋放了那個監(jiān)控節(jié)點
優(yōu)化后的成果展示
tp99：30ms左右降低到10ms左右
服務(wù)器占用：從35個節(jié)點到180個節(jié)點左右
