九月份接到一則需求有關廣告業務的gap報表需求（gap這裏可以理解爲公司內部廣告曝光/點擊監控數據和第三方廣告曝光/點擊監控數據的差值與公司監控曝光/點擊數據的比值）。
產品文檔涉及數據較多，均出自不同的數據表，查詢數據是來自調用rpc服務獲取的基礎數據，表報接口拼裝統一數據對象對外展示。服務主要分爲三個維度查詢，按天查詢，按小時查詢，按地域查詢，由於按小時和按地域查詢查詢條件都是拿到具體的廣告ID查詢廣告拼裝每條廣告在不同時間範圍內（一天24小時）或在不同地域（大概33個省）的數據計算展示，數據量有限查詢均爲700ms左右，速率還可以。但是在按日期查詢廣告數據時，按時間範圍，默認查詢當天的在投的並且匹配到監控公司的廣告數據大概有20-30條左右，數據顯示量也不大，但是查詢耗時達到4秒左右，開始以爲是因爲我使用內存分頁的原因，但是加日誌排查耗時，內存分頁在現有的數據量下耗時基本爲0，主要耗時的位置在業務邏輯for循環去封裝數據的buildAdGapBO方法上，很納悶爲什麼爲在這個方法上，幾經周折，提取出來內部調用通過外部批量查詢的數據列表生成map數據，buildAdGapBO中通過map獲取對相應的依賴對象進行數據封裝，優化上線後，效率有所提升，但每天的數據基本保持在4秒左右查詢，（翻看了一下其他頁面查詢代碼，數據量都不小，但查詢在1秒一下，疑惑，爲什麼其他的查詢能在一秒一下查詢出來？難道是因爲內存分頁？可是這個查詢耗時打印內存分頁並不耗時呀，難道是因爲數據來源是通過rpc的調用？還是因爲查詢的條件沒有索引？按條件一個表一個表的排查，都有索引啊，並且條件是可以走索引的。。。）
思前想後，百思不得其解，晚上回家的路上想到H神，對向H神求解，於是向H神提問，把我的問題和H神講了一邊，H神回覆用Arthas排查調用耗時。我問線上的也可以嗎？可以的，不要猜，用Arthas 可以很清楚的查出服務調用耗時問題。我回復好的，明天回去就試一下。
第二天一早來到辦公室，立馬查找Arthas的使用文檔，因爲我司用的是mac安裝方式也挺方便。起初擔心自己的操作會對公司服務造成影響先向同事老師說明情況，因爲老師沒有用過線上排查耗時的問題，所以提示可以先在聯調環境下排查，並告訴我了安裝方法。
1.搭建聯調環境
2.登錄到聯調環境
3.在聯調服務器上安裝Arthas因爲我司用的是mac所以我的安裝命令使用的是
curl -L https://alibaba.github.io/arthas/install.sh | sh
顯示Arthas install successed.表明安裝成功
3.直接在shell下./as.sh就進入了交互頁面
4.trace 命令就可以查詢接口耗時 使用是trace 接口的全路徑.接口所在的類名 接口名
命令輸入後，調用接口查詢，就會有接口的查詢詳情打印在下方，注意要多調用幾次，只看一次的查詢結果可能會出現某個接口查詢突發性的時間過長，誤導排查結果。
查詢結果大致如下：（上邊爲單個接口的耗時，下邊爲for循環接口的耗時，均爲平均耗時）
找出耗時點，發現耗時問題在我每天查詢的結果是在投廣告的指定幾十條，但是在投廣告的過濾在buildAdGapBO方法之後，也就是調用buildAdGapBO封裝數據的廣告會遠遠大於指定的廣告數量，所以優化方法就很快得出，就是在調用buildAdGapBO之前提前把廣告過濾了。減少不必要的buildAdGapBO調用，以此來優化。
果不其然，過濾後速率從原來的4秒提升至1.7秒左右。
期間遇到的問題點：
1.在trace時遇到No class or method is affected, 
2.根據提示sm 發現方法是加載成功的
3.使用cat /root/logs/arthas/arthas.log 命令得到如下的日誌 Method too large 的error信息
這裏說的是我的方法過大，確實是超過了300行，解決方法是把這個方法提取讓這個方法儘量的小。
下邊附上我的參考文檔：（還有很多技術博客，就不一一列舉了）
https://alibaba.github.io/arthas/install-detail.html
最後再次對H神表示感謝，一點點進步就可以滿足一整天的成就感，無比的開心