鯨品堂｜性能優化手記上篇之【原則】&【方法】

現象：某產品發布上線后經過一段時間的運行，管理員在管理門戶上查詢訂單信息的操作耗時增加，影響操作體驗。

分析：分析訂單信息查詢功能，發現訂單信息展示時需要展示商品名稱，而商品名稱與訂單信息不是同一個數據庫，每次都需要根據商品ID調用服務去查詢商品名稱回來。在服務調用過程中當調用的服務次數多了，開銷就增加了。

解決方案：根據訂單信息第一屏中展示的內容，商品名稱是需要通過服務調用獲取的，因此采用空間換時間的方式將商品中心g_goods表的數據冗余一份到訂單中心。當進行訂單信息第一屏數據展示時，將訂單中心的o_order_item與g_goods關聯查詢，減少中心間服務調用。

現象：現場有個客戶使用的小程序，從客戶點擊登錄按鈕到客戶信息展示的時間平均需要3S左右，無論在業務忙時還是在業務閑時耗時都差不多。

分析：對客戶登錄后的處理邏輯進行分析，發現展示的客戶信息很多是依賴于調用外部服務返回，并且服務使用同步的方式進行調用。當一個外部服務響應不及時，則會造成客戶登錄后信息加載緩慢，甚至出現空白頁面的情況。

解決方案：從客戶體驗出發將客戶信息進行分塊，系統內的客戶信息在客戶登錄后優先返回到前端進行渲染展示。對于調用外部服務獲取客戶其他信息的處理改為異步調用的方式，當外部服務返回信息后再加載到前端頁面進行展示。

優化后：客戶登錄后信息展示的耗時從3S提升到0.5S。

現象：客戶在平臺上訂購權益商品后，客戶無法立即使用購買權益商品的手機號碼登錄平臺使用，引發客戶投訴。

分析：分析客戶無法立即使用權益的原因，發現是客戶訂購的權益商品沒有立即送往對應的權益提供商進行開通導致。進一步分析發現沒有及時送的原因是平臺生成權益商品訂購單后，需要送多個外部系統，而且是按照順序一個個送。當其中一個系統出現問題后其它系統將被堵住，而送權益提供商的處理恰巧排在最末。

解決方案：調整權益商品訂購單送外部系統的處理邏輯，將現有串行送外系的操作調整為并行同步給外系統，實現權益商品購買后能夠立即送往權益提供商進行開通，各業務系統之間的操作相互隔離，互不影響。

現象：某產品查詢客戶可訂購商品的功能，經過兩年的需求迭代，校驗規則越來越多，查詢效率越來越慢。

分析：借助Arthas工具分析商品查詢調用鏈上的每一步耗時，發現規則引擎執行耗時嚴重。進一步對規則引擎進行分析發現：

① 單個規格執行耗時很短，只需十幾毫秒，但存在300多個規則，導致總體規則執行經常超過4S；

② 每次請求都重新生成了多個規則引擎對象，導致規則對象內存占用高達幾G，從而頻繁觸發FullGC；

③ 業務邏輯對執行的規則缺少細分，所有規則都會執行。

解決方案：通過優化規則執行方法：

① 梳理出簡單規則，簡單規則不使用規則引擎engine.eval，改為直接比較法進行判斷；

② 創建規則引擎池JsScriptEnginePool，減少規則引擎重復創建；

③ 業務規則增加狀態，只檢索有效的規則進行執行。

優化前：10個并發， tps在1.6左右，請求平均耗時7.5s（再增加并發量就大面積請求異常）。

優化后：100并發用戶時，平均tps為102，請求平均耗時在1s內。

現象：某項目近兩年的業務發展較快，每天新增訂單大約6W?？蛻粼谶M行訂單查詢時耗時越來越長，每次查詢耗時達到3S以上。

分析：分析訂單查詢功能發現耗時長的主要原因是訂單的數據量多，造成查詢語句執行效率低。對業務場景進行分析發現1~2個月內的數據訪問率在92%以上，3~6個月的數據訪問率在7%左右，超過6個月的數據訪問率在1%以下。

解決方案：根據分析結果對訂單表oi_order_item進行瘦身，新增his_oi_order_item表用來存放超過半年的數據。同時對his_oi_order_item表的數據訪問提供新服務。通過將訂單表oi_order_item的數據化整為零，大幅提升訂單查詢效率，數據庫壓力下降明顯。訂單查詢耗時從原來3S下降到0.5S。

現象：系統在已經上線運行超過半年，一直存在操作卡頓的現象，業務高峰期甚至5分鐘就出現一次。

分析：通過分析系統出現卡頓時的應用狀態，發現rights-intf應用在卡頓時所有的線程都出現響應不及時的情況，并且rights-intf應用也在頻繁觸發FullGC操作。在業務高峰期每5分鐘觸發一次FullGC。每次FullGC后老年代內存使用率從98%左右下降到50%左右。

解決方案：根據分析結果倒推，懷疑rights-intf應用的JVM Xms和Xmx設置太小，導致頻繁觸發FullGC操作。檢查rights-intf應用的JVM Xms和Xmx 配置的為1G。將1G改為3G后觀察rights-intf應用未發生FullGC操作，系統運行平穩，卡頓現象消失。