2016-03-11-信息系統實踐手記2-客戶端啓動速度調優思路

---

layout: post
title: 2016-03-11-信息系統實踐手記2-客戶端啓動速度調優思路
key: 20160311
tags: 客戶端 調優 測試 服務器 GIS WPF 模塊 壓力 瓶頸
modify_date: 2016-03-11
---

信息系統實踐手記2-客戶端啓動速度調優思路

說明：

• 本文發佈於: gitee,github,博客園
• 轉載和引用請指明原做者和鏈接及出處.

正文：

• 信息系統實踐手記系列是系筆者在平時研發中前後遇到的大小的問題，其中比較典型的內容加以收集和分享。
• 信息系統實踐手記目錄：博客園(或查看源碼的README.MD文件)

摘要：

• 分享調優的我的經驗，以及客戶端啓動速度調優的一個具體實例（本文可能須要讀者具有必定基礎）。

正文

1. 什麼是調優？

實踐中遇到不少同事很熱衷於發現，某某模塊啓動太慢，處理太慢，須要調優。而後找來某個框架或者類庫，用上試一試，發現有改善，因而欣喜。
這特別好，積極性是你們最喜歡的，但真正的調優實際上是很複雜，這裏分享我的的少許見解。

問：怎麼算一個軟件模塊已經很優秀了？ 
答：四個字"收放自如"。

能充分發揮（吃掉）硬件資源：如CPU/內存/網絡帶寬/IO；若是不限制，甚至能升到95%或更多，把硬件用足；
能按需調節硬件資源佔用比：針對各類硬件資源（CPU/內存/網絡帶寬/IO）既能發揮到極致，又能按需消減佔用，好比CPU不能超過75%；
受控/敏感/穩定：模塊要充分受控，經過配置文件或額外信令能很好控制；並且要對控制響應快，快速調整到位；長時間穩定運行；

原則多是：正確性>穩定性>韌性>敏捷性

解讀：正確是必須的，不然無心義；正確後要長時間穩定的正確表現則須要穩定；穩定後要講究資源佔用的靈動變化，貼合要求，這是韌性，很難；最後是敏捷性，要快速反應，就像特種部隊的快速響應，那就比較完美了。

問：何時軟件模塊須要調優？
答：很簡單，沒有達到上述「收放自如」的模塊，就有調優的餘地。說明原來開發沒有作「足」。

問：何時不該該調優？
答：
能硬件升級的不調優：如增長CPU/MEM/磁陣/帶寬等硬件資源的，儘可能不要軟件調優。這樣最經濟實惠，通常狀況下是划算的。
不搞清楚業務模型和壓力模型就不調優：對一個軟件模塊，若是都不瞭解清晰其業務模型（場景模型），主要功能，以及針對他們的壓力模型，你怎麼知道你的模塊不達標呢？雖然你的模塊按照上述要求，沒達到客觀的「收放自如」，但主觀上也許已經達到產品經理的要求了，那就不建議優化。
沒有好的審計手段不調優：要找到瓶頸或權重問題，常常須要測試和計量，好比作業務的時間消耗分析等。在作這些的時候，若是遇到困難，千萬不能盲目去嘗試優化，要科學和理性。因此必需要有一個可重複測量和審計軟件模塊運行狀況的手段。沒有手段，妄談優化，但實踐中每每你們很喜歡猜想，由於猜想容易。
不找到權重問題不調優：即使找到了一堆問題，但根據二八原理，只有找到核心問題，佔比重大的權重問題，最重要問題，才須要先解決它。其餘次要的問題能夠記下來，千萬不要由於容易，順手先作次要問題。不然容易引入了額外的變化（好比新BUG），影響對核心問題的解決。
不成熟的框架不使用：有些同志常常喜歡嘗試各類新鮮的類庫，這對拓寬知識面是好的。可是新框架不成熟，行業地位不穩定，社區資源不豐富，這都不利於使用它。通常建議採用主流成熟框架，排名前三，社區資源充分，案例較多，功能專著於某領域。不建議嚐鮮。
人力經驗不足不調優：調優很耗人力，考驗普遍的知識面和經驗積累，如非準備充分，不要輕易嘗試調優。有時候找到一個專家來優化一週，比投入5個普通開發折騰1個月還有效率。
不熟透軟件模塊就不調優：調優時必須對軟件模塊的細節爛熟於心，經驗必須足夠，不然一羣不瞭解的人，即使是專家，妄談優化。
還有更多慘痛經驗，不一一列舉，你們要慎重決定。

2. 具體到某個細節好比「調優客戶端的啓動速度」，怎麼弄？

具體調優的過程確定不簡單，但仍是愉快的，「痛並快樂着！」。舉例供參考。
就拿手記1「信息系統實踐手記1-列表數據展示的6個要素」中提到的一個包含地圖（GIS）業務的客戶端來講。

客戶端軟件結構：
客戶端用C#的WPF框架開發GUI界面；
底層VC是業務功能引擎，它供WPF上層界面調用；提供好比播放視頻（StreamPlay）等功能函數；
WPF的GUI界面層還嵌入了IE的OCX控件，控件中跑JSP代碼，以便調用提供JS接口的各類GIS引擎（百度/公安PGIS/第三方）；
因此C的代碼（C#）和JAVA/JS代碼（JSP）的，都和後臺SERVER交互，獲取信令和數據（因不一樣場景和應用而有差別）。
信令：通常指信令協議，不管是國家標準GB，或國際標準如SIP，或私有定義的協議，他們主要爲了讓不一樣平臺或軟件模塊作溝通，數據量通常不大，多爲傳遞核心數據諸如「設備列表」，「用戶帳號權限」等等；
數據：特指數據量較大的內容（針對視頻應用），通常指視頻信息，音頻信息，或者交換的大量信息主體。以示對信令的區別；

客戶端啓動過程：
初始化界面並等待用戶帳號密碼登錄；
客戶端W從另外一視頻平臺A拿來它管理的設備列表；
客戶端W從GIS地圖引擎平臺B拿來地圖資源（資源經過IE的OCX控件中JS接口展示）；（通常是非矢量的點陣方塊地圖瓦片資源）
客戶端W的WPF/GUI層執行本身初始化邏輯並和後臺C溝通；
客戶端W的JSP層執行本身的初始化邏輯並和後臺C溝通；
登錄完成，界面穩定；
就這一個過程來講，其實很簡單。但也能夠說複雜，由於涉及到三個平臺（A,B,C）和W交互，涉及多種信令，多類數據傳遞。
既有同步的信令接口，它須要暫停代碼執行等返回值再繼續；
也有異步的信令接口無需中斷當前代碼運行就立刻返回，但需事先設定回調函數或回調機制等待異步回調再處理。
實踐中發現客戶端啓動到登錄完成，整個過程比較慢，好比2萬個設備從A平臺同步過來，而後從B平臺獲取GIS地圖資源，再和的後臺C交互，最終呈現並穩定，用了2分鐘，用戶以爲很慢。
固然，用戶能夠有本身想法（不管是否合理），但搞研發的人仍是要先調查，再客觀分析判斷，肯定調優思路。

調優過程簡單描述：
針對W和A平臺交互過程P1：在A和W之間兩端抓包，分析出來兩邊印證結果，分析時間/信令/數據狀況。（有時候和第三方系統對接，不兩邊抓包對方會否定！）。
針對W和B平臺交互過程P2：在B和W之間兩邊抓包分析如上。（如對端無抓包條件，那也只能先抓本身側作分析）
針對W和C平臺交互過程P3：在我客戶端W（JSP和WPF是邏輯上獨立的兩塊）和我後臺C之間兩邊抓包，同上分析。
獲得三個基本獨立的過程P1，P2，P3，分析後，發現P1較慢，且慢在A平臺，因而讓A優化接口，實測有提高，兩邊實測P1提高了速度；
但結合P2，P3，整體仍是較慢不達標，繼續分析。發現P1，P2，P3互相不依賴（獨立），從原來串行改成並行處理，讓三個過程併發，提高了很多速度。
緣由：通常開發人員按照天然習慣，老是順序（串行）開發功能，作完1,2,3，再作4,5,6，並沒有時空概念，這是一大問題。
解決：經過引入適當的框架；或者常常作時空性能分析，理解業務的串並特性（這考驗研發人員思惟）；或者持續重構優化；

從2分鐘提高到30秒登陸，但用戶仍是不解渴。其實P1，P2，P3三者取最長的P3是30秒，額外開銷是5秒內暫時不計。
大流程P1，P2，P3已經併發運行，無可優化。但發現最長時間的P3過程當中，W本地啓動時總感受太慢，不正常。
找到底層協議棧的負責人仔細code review，發現好久未修改過的底層信令協議棧，在其初始化中竟然自動作了一個沒必要要的高層業務邏輯，額外消耗了10秒，這是不該該的。
較爲底層的協議棧不該參與高層業務邏輯，它只須要爲上層提供功能就能夠了！修改後提高了速度到20秒。
緣由：協議棧不會常常維護，開始作的時候也許不必定是高手或牛人，有些問題很隱蔽，短時間不影響使用，在大數據量大壓力下才能發現問題。也多是後續圖方便，爲實現某個功能，不恰當的引入了BUG。
解決：協議棧必須標準化；儘可能用成熟框架；儘可能在初期多設計研究分析定型（各類使用者和各個軟件模塊多多參與）；研發組織要有核心team維護核心代碼（包含協議棧）；

優化上還有不少細節（好比更細緻的拆分了JSP/JS的異步更新等內容）再也不詳述。
用戶仍是不解渴，說最好10秒，且贊成並要求你緩存全部必要數據，容許數據由於緩存而不一樣步！
那咱們天然贊成。咱們從技術上說明了，當前模型和數據量，10秒啓動是合理的，如要提高，就要權衡和犧牲。
贊成用戶的建議，將數據持久化到本地，啓動能更快，可是數據的新鮮度（及時性）確定會下降，有可能須要引入額外的同步刷新機制，這是一個平衡，完美的解決方案並不存在，合適就好。
最後，用戶也贊成了咱們最開始就提出的提高硬件的要求，購買了I7六代的超級臺式PC，進一步提高了（網絡和對端憑他之外的本地過程）速度，這是硬件提高性能的好例子。這要看用戶的預算了。

說明：本文涉及的全部專有名詞，包括協議名，軟件名等，皆來自於網絡信息，僅供參考，如涉及版權等問題，請及時聯繫做者處理。

END