昨天專案上生產，把最近開發的程式碼合併後，達成war包上線。同樣的war包，放在測試環境三分鐘就啟起來了，放到生產上啟動半個小時，終止程式則直接卡掉。cup達到滿負荷。由於集成了兩臺server，導致啟動完成更慢。但是改回上一次war包又恢復正常。

出現的war包釋出突然異常緩慢的原因，我們分析了框架，看了jdk的版本，是不是快取導致的，由於頁面較多，是不是靜態資源掃包費時？經過分析發現快取的嫌疑很大。因為別的部分幾乎和原來的部署方式一樣。框架和jdk沒變動過。頁面這些靜態資源也增加不多。而快取載入的東西比較多，也是費時間較長的，這是迭代看合併的資源記錄，這塊有新內容更新。涉及到查資料庫。並且日誌記錄一到初始化容器就卡住。資訊和資料庫有千絲萬縷的關係。雖然定位到快取，但一時也沒找到問題點。

最後在websphere的系統日誌中，發現有一個快取的方法載入時間非常長，然後根據這個方法，順藤摸瓜找到病因：有一個方法在載入快取查詢資料庫時，載入的人員表資料量比較大，加上聯表查詢的語句沒有優化，導致執行效率低，導致專案一載入到這裡就卡住。由於專案上線比較著急，就臨時註釋掉了這塊的快取，重新部署，果然釋出又恢復了正常。這就找到了病因！

經驗總結：
1.websphere的系統日誌和專案日誌同等重要，不要忽略了這個。
2.帶有前臺頁面的web專案和只提供介面的soa專案有個最大的區別就在於有頁面的web專案一般都涉及比較多的快取要提前載入。而soa快取比較少。其次才是框架。
3.如果不是第一次部署專案，而最新一次的專案部署突然異常緩慢的原因主要定位於最近這次迭代更新的內容，而不是框架，jdk和靜態頁面內容增多。重點在於啟動時就要查庫的後臺方法或者js。最近就遇到兩例特殊sql查表出現查表異常緩慢，簡單的一個兩表聯表查詢，就能耗費好幾分鐘。
4.sql聯表查詢緩慢的主要原因不在於你設定了多少查詢條件，而是這兩個表的資料量巨大，幾百萬甚至更多條記錄。比如人員資訊表和一些保單表。
5.注意到生產環境和測試環境的最大不同：資料量不在一個量級上。