業務不停的迭代，加上打工人換了一波又一波，導致很多業務介面特別重，可讀性非常的差。最近專案在重構優化，部分介面平均響應時間在 1.5s 左右，對於使用者體驗來說，非常的不友好。本文旨在提出幾個介面優化的一些常用的辦法。
1、優化的準則
一切的前提是業務價值需要。如果沒有足夠的價值，那麼可讀性才是第一，效能在需要的地方是no.1，但不需要的地方可能就是倒數第一，因為非同步，併發程式設計，邏輯快取，演算法真的會加劇系統的複雜度，得不償失。。當下技術框架出來的軟體差不到哪去，沒有這種及時響應訴求的地方，削峰下慢慢跑就是了。
2、度量效能的指標：介面的響應時間
通常條件下,人眼的識別連貫影象的速度是24幀/秒,也就是1000毫秒/24幀,大約為40ms(毫秒)。達到或者超過這個速度的連貫影象, **時就不會形成卡頓的感覺。從使用者體驗的角度上來說，介面的響應時間應該收斂在 200ms 內。比如 web 應用的響應時間，如果超過 5s，那幾乎是不可忍受的。所以一般來說，度量效能的指標是系統介面的響應時間。但是單次的響應時間是沒有意義的，你需要知道一段時間的效能情況是什麼樣子的。
度量的指標有：1、平均值 2、最大值 3、最小值 4、分位值
3、優化的方式
【應用程式層面】
3.1、快取：
一級快取或者多級快取。
針對一些不變的資訊，可以通過快取來替換多次請求或者查詢。
3.2、非同步：
通過多執行緒進行非同步。分而治之處理大人物，併發程式設計，採用多執行緒並行的方式處理業務。
使用場景：
【業務和訊息耦合】【大事務=小事務+訊息】
通過中介軟體非同步，比如 mq。主要用於複雜業務的拆分，像狀態變化後的外部系統通知、業務監控，資料同步等操作，無需在主流程中做的事情，都可以拆出來。走 canal 監聽表資料變化，推 mq 保最終一致的方式從業務專案中完全解耦出來。
3.3、延後運算
低頻、運算耗時的計算，都可以延後運算。
3.4、批量、合併，增加上下文提高復用
批次請求，代替多個多次的請求。針對業務鏈路都需要的資訊，盡量通過上下文來處理，避免多次請求。
3.5、提高復用
【元件層面】
資料庫優化：1、sql 2、索引 3、連線池
4、一些工具
找問題的話主要有三個方法，監控，工具和壓測。線上流量引流的工具常見的有： tcpcopy, goreplay
1.採用非阻塞的rpc呼叫（高效的遠端請求模式，採用容器的覆蓋網路我認為也算）
2.將計算密集和io密集的的邏輯分割開，單獨執行緒池，調整執行緒比例壓榨單機效能（或者說找拐點）。
3.做快取，io耗時的快取和計算耗時的快取（多級快取，資料壓縮降低頻寬）。
4.採用享元模式，用好物件池和本地執行緒空間，儘量減少物件建立與銷毀的開銷，提高復用。
5.業務拆分，像狀態變化後的外部系統通知，業務監控，es或solr等副本資料同步等操作，無需在主流程中做的事都拆掉。走canal監聽表資料變化，推mq保最終一致的方式從業務專案完全解偶出來。
6.fork_join，分而治之的處理大任務。併發程式設計，採用多執行緒並行的方式處理業務。（規避偽共享，減小鎖力度，採用合適的鎖）。
7.資料庫配置優化，查詢優化。（儲存優化比較頭疼，畢竟不按業務拆單點跑不掉，單點效能就要命。基本只能記憶體庫先行，後台同步資料做持久。然後記憶體庫多副本，自修復，保留一系列自修復失敗的修復手段）
Eureka響應時間優化
1 心跳傳送時間間隔 eureka.client.leaserenewalintervalinseconds 2 心跳檢查間隔 eureka.server.evictionintervaltimerinms 3 readwrite 快取 同步到 readonly 快取中的 間隔時間 eureka.s...
php頁面靜態化 優化頁面響應時間
如 動態頁面靜態化 優化資料庫 使用負載均衡 使用快取等都可以優化頁面響應時間。如果頁面中的一些內容不經常改動 幾個小時 幾天或更久不做改動 這個時候將動態頁面靜態化是非常有效的加速方法 比如 新聞發布系統 文章發布系統等 動態頁面靜態化的好處 1 減少伺服器指令碼的計算時間 2 降低伺服器的響應時...
通過Ethereal測量響應時間
我們在測試過程中有的時候響應時間可以通過客戶端效能測試工具獲得，但是有的時候不能，特別是非同步傳輸的系統，當系統請求發出後系統不是及時響應，而是通過後續的應用獲取資訊，這種情況下現有客戶端效能測試工具很難解決響應時間的衡量。因此在類似於此類測試過程中我們可以通過 ethereal 類似的協議分析工具...