做了這麼久開發，終於涉及到效能優化了
原因是開啟乙個頁面花了2-6秒，被提了bug
不得不說自己有點小白，嘗試了非同步執行緒和把單次的dubbo查詢優化成批量的查詢。
但是這兩種嘗試都沒有宣告成功
出了問題首先要找到問題在**
既然是耗時，那就要看看到底**耗時最多（這裡要說一下，因為我是改別人的**，所以對業務邏輯不是很清楚，完全靠debug去改。如果有精力，最好能掌握業務邏輯，這樣改起來更得心應手）
我太忙於優化dubbo查詢了，把單次改為批量查詢後，我發現並沒有減少時間。與沒改前基本持平。
不過dubbo優化也是必須做的，為後續做準備。
正題開始了：我開始找哪個dubbo耗時最多。
整個方法用了5個dubbo吧。在我將單次改為批量後。我又發現了有個dubbo的查詢結果可以復用，就又省去了乙個dubbo。現在只剩下4個dubbo了。問了大資料的大神，hbase的效能很好，肯定不會很耗時。事實卻是如此，所以排除了這個dubbo
然後在剩下的dubbo前後都加上了耗時計算
結果發現。返回map解決辦法就是加快取。不過這裡有兩個地方，乙個是我本地查詢結果家快取，還有一點是資料大神提醒我的。dubbo實現類裡面實際查詢了90多次的mysql，不如直接把查詢結果加快取。但是就算把查詢結果加了快取，也沒有很減少時間，因為畢竟要查詢90多次redis。最後還是要在使用方的查詢結果裡加快取。果然加了快取以後就好了。耗時幾十ms。目前符合需求了
不過有個問題就是快取的時效性。由於我目前在dubbo的實現類和dubbo服務的使用方都加了快取，這個時效性的問題還需要考慮一下。不過在更新資料的時候更新redis快取是很有必要的。
好了，先寫這麼多吧，下班回家。
記錄一次效能優化
前幾天領導扔給我乙個任務讓我對某個業務系統進行效能優化，當前現狀是每秒50併發響應時間就在30s左右，之前沒有接觸過效能優化完全沒有頭緒。領導說公司買了一套dynatrace軟體可以直接用這個軟體進行分析。在測試環境壓測發現情況如下 經統計乙個介面中共列印了80多個debug級別的log，耗時巨大。...
第一次效能測試 http load
http load 以並行復用的方式執行，用以測試webx伺服器的吞吐量與負載。但是它不同於大多數壓力測試工具，它可以以乙個單一的程序執行，一般不會把客戶機高斯，還可以測試https類的 請求。http load用法 注 常用方式 http load r 200 s 900 http.txt 2 2...
一次效能調優的實戰
專案情況 是乙個大型公司的內部辦公系統，該系統有兩個和一般企業應用不太一樣的特點 一是使用者量非常多，人員數達到2w左右，另乙個是採用分級管理的形式，各個分公司資料分開管理。我們的定位 我們是作為業務平台的提供商參與這個專案的，我們提供底層的開發平台，系統整合商在此基礎上進行二次開發。在專案從開發到...