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

現象：某（mǒu）產品發布上線後經過一段（duàn）時間（jiān）的運行，管理員在管理門戶上查詢訂單信（xìn）息的操（cāo）作耗時增加（jiā），影響操作體驗（yàn）。

分析：分（fèn）析訂單信息查詢功（gōng）能，發現訂單信息展示時需要展（zhǎn）示商品（pǐn）名稱，而商品名稱與訂單信息不是同一個數據庫，每次都（dōu）需要根據商品ID調用服務（wù）去查詢商品名稱回來。在服務調用過程中當（dāng）調用的服務次數多了，開銷（xiāo）就增加（jiā）了。

解決方案：根據訂單信（xìn）息第一屏中展示（shì）的內容（róng），商品名稱是需要通過服務調用獲取的，因此采用空間換（huàn）時間的方式將商品（pǐn）中心g_goods表的數據冗餘一份到訂（dìng）單中心。當進行訂單信息第一屏數據展示時，將訂單中心的o_order_item與（yǔ）g_goods關聯查詢（xún），減少中心間服務調用（yòng）。

現象：現場有個客戶（hù）使用（yòng）的小程序，從客戶點擊登錄按鈕到客戶信息展示的（de）時間平（píng）均（jun1）需要3S左右，無論在業務忙時（shí）還是（shì）在業務閑（xián）時耗時都差不多。

分析：對客（kè）戶登（dēng）錄後的處理邏輯進行分析，發現展示的客戶（hù）信息很多（duō）是（shì）依賴（lài）於調（diào）用外部服務返回，並且服務使用同步的方式進行調用。當一個外部服務響應不（bú）及時，則會造成客（kè）戶（hù）登錄後信息加載緩慢，甚至出現空白頁麵的情況。

解決方案：從客戶體驗出發將客戶信息進行分塊，係統內的客戶信息在客戶登錄後優先返（fǎn）回到前端進（jìn）行渲染展示。對於調用外部服務獲取客戶其他信息的處（chù）理改為（wéi）異步（bù）調用的（de）方式，當（dāng）外部服務返回信息後再加載到前端頁（yè）麵進行展示。

優化後：客戶登錄（lù）後信息展示的耗時（shí）從3S提升到（dào）0.5S。

現象：客戶在平台上訂購權益商品（pǐn）後，客戶無法立即使用購買權益商品（pǐn）的（de）手（shǒu）機號碼登（dēng）錄平台使用（yòng），引發客戶投（tóu）訴。

分析：分析客戶無法立即使用權益的原因，發現是客戶訂購的權益商品沒有立即送往（wǎng）對應的權益（yì）提供商進行（háng）開通導致（zhì）。進一步分析發現沒（méi）有及時送的原因是平台生成權益商品訂（dìng）購單後，需要送多個外部係統，而且是按照順序一個（gè）個送。當其中一個係統出現問（wèn）題後其它係統將被堵住，而送權益提供商的處理恰巧排（pái）在最末。

解決方案：調（diào）整權益商品訂購單送外部係統的處理邏輯，將（jiāng）現有串行送外係的操作調整為並行同步給外係統，實現（xiàn）權益商品購買後能夠（gòu）立即（jí）送往權益提供商進行開通，各業務係統之間的操（cāo）作相互隔離（lí），互不影響。

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

分析（xī）：借助Arthas工具分析商品查詢調用鏈上的每（měi）一步耗時，發現規則（zé）引擎執行耗時嚴重。進一步（bù）對（duì）規則引擎進行分析發現：

① 單個規格執（zhí）行耗時很短（duǎn），隻需十幾毫秒，但存在300多個規則，導致總體規則執行經常超過4S；

② 每次請求都重新（xīn）生成了多（duō）個規則（zé）引擎對象（xiàng），導致規則對象內存占用高達幾G，從（cóng）而頻繁觸發FullGC；

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

解（jiě）決方案：通過優（yōu）化規則執行方法：

① 梳理出簡單規（guī）則，簡單規則不使用規則引擎engine.evals，改（gǎi）為直接比較（jiào）法進行判斷；

② 創建（jiàn）規則引擎池JsScriptEnginePool，減少規則引擎重複創建；

③ 業務規則增加狀態，隻（zhī）檢索有效的規則進行執（zhí）行。

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

優化後：100並發（fā）用戶時，平均tps為102，請求平均耗（hào）時在1s內。

現象：某項目近兩年的業務發展較快，每天新增訂單大約6W。客戶在進行（háng）訂（dìng）單查詢（xún）時（shí）耗時越來越長，每次查詢耗時達到3S以上。

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

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

現象：係（xì）統在已經上線（xiàn）運行（háng）超過半年，一直存在操作卡（kǎ）頓的（de）現象，業務高峰期甚至5分鍾就出（chū）現一次。

分析：通過分析係統（tǒng）出現卡頓時的應用狀態，發現rights-intf應用在卡頓時所（suǒ）有的線程都出現響應不及時的情況，並且（qiě）rights-intf應（yīng）用（yòng）也在頻繁觸發FullGC操作。在業務高峰期每5分（fèn）鍾觸發（fā）一次FullGC。每次FullGC後老年代內存使用率從98%左右下降到50%左（zuǒ）右。

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