事件起因：
樓主今年手上有個專案，上線後，每天大概15w的訪問量，單台pod(公司用的docker)，tps在6-7之間，第一次壓測的時候，最好的情況是5個pod，tps達到了36。樓主當時有點絕望，因為跟我們其他的服務上千的qps差距太大了，但是考慮到這個服務的特殊性，所以沒有仔細去驗證效能這麼差的原因在哪兒。
上線1月多，其實沒有遇到過該服務出現併發特別大導致服務不可用，所以也還算穩定。
雙11前，公司在搞全鏈路壓測，當然也給我這個服務提要求了，希望能達到1k tps。樓主當時聽聞這個訊息，人都傻了..粗略算了一下，起碼得200臺機器啊。
於是為了這個目標，樓主進行了第二次壓測，在壓測的時候，發現單台伺服器的cpu一直穩定在7%，跟第一次完全沒有質的變化，於是，沒辦法，只能讓運維這邊加機器，直接乾到30個pod，再次壓測，tps最高能達到170了。其實對於樓主的業務來說完全夠用了，但是耐不住上面的大佬提的要求啊，無奈，在170的壓測報告提出後，領導又找上來了，說為什麼上不去，瓶頸卡在哪兒？於是樓主開始了漫長的驗證之旅：
1.由於壓測的時候，cpu一直很穩定在7%，檢視了tomcat引數後，以為是tomcat中的啟動時執行緒數（100）搞小了，但是最大執行緒數也有800，當時不能驗證問題所在，所以找了臺vm去測試，但是遇到很多問題，環境問題，機器數量問題，最終擱置了。
於是檢視**，這個http連線在**被呼叫的，因為樓主是使用的第三方服務提供的skd包，這個http連線的配置就是使用的預設的，最大連線數配置的是100，問題就在這兒。於是跟第三方溝通後，由他們優化後，重新打包；第二天，重新壓測，發現使用新的sdk後，
30個pod在800併發的情況下，能達到930tps了，900併發的時候，已經壓到對方瓶頸，耗時直接翻了3倍。在800併發的時候，cpu最高才40%，所以判斷其實在這個併發下，還有優化的空間，跟運維那邊溝通後，直接從30個pod減容成10個pod，重新壓測，發現在800併發的情況下依然可以做到920tps，此時cpu最高80%。由此判斷：在10個pod數就可以支援將近1ktps，成功完成了上面大佬的要求。
優化之路路阻且長，但是走的越遠越能成長，各位共勉！
記錄一次壓測問題
同一套程式，之前放在伺服器上使用，公司內部壓測和發布給客戶使用，均未出現問題。後由於客戶業務需求，將其移植到嵌入式平台。公司內部壓測過程中，出現三種異常。問題1 大併發壓測，服務程序被killed掉。問題2 大併發壓測，服務掛掉，最後的列印為底層的錯誤日誌。問題3 大併發壓測，服務掛掉，列印另外的底...
記一次SQL優化
問題發生在關聯主表a 4w資料量 和副表b 4w資料量 關聯欄位都是openid 當時用的是 left join 直接跑sql，卡死 伺服器也是差 優化1 改left join 為join，兩者區別就是left join查詢時已主表為依據，該是幾條就幾條 就算副表沒有關聯的資料 join如果副表沒有...
記一次RabbitMQ生產事件
早上來跟我說這個功能一直沒有推送資料，說實話，這個話讓我聽來現在還有點後怕，乙個功能去年上線，也是剛入職的開發的功能，這不鬧嗎？對我形象的影響太大了，所以上午就放下一切，對這個功能進行排查。耽誤了一上午的時間，對我開發進度影響也很大。1.第一時間看了生產環境mq的資料，發現只有七千條資料，同時看了第...