APP精細化HTTP分析（二）：響應性能分析與優化

01-25

前排：正文中獲取APP端所有HTTP請求的方法請參考APP精細化HTTP分析（一）：別再只是代理抓個包了

上篇講到介面錯誤代碼，這次說到響應性能，首先需要仔細了解一下HTTP請求響應的過程。一次完整的請求響應過程有這麼幾個過程： [連接建立過程] -> 發送 Request Header -> [發送 Request Body] -> 等待 Response Header -> [下載 Response Body] 其中 []是可選的，其中連接建立我們不會過多涉及，一般是DNS和TCP三次握手，如果已經連接（比如連續向同一個伺服器發多個http請求）則不會有這個過程。 Request Header包括了請求的方法，就是我們常說的GET、POST；請求URL；還有一堆Headers；可選的有一個 Request Body，比如一個 POST 請求的表單內容就是存在 Request Body 里，或者上傳的文件也會放在 Request Body。

伺服器收到這個Request，就會進行處理，最終給APP一個Response （header + 可選body）；Response Header包括狀態碼（如200/404/500），一般4xx表示APP請求錯誤，5xx表示服務端錯誤；Response Header也是一堆，其中比較重要的有：

Content-Length: Response Body的長度
Content-Type: Response Body的 MIME類型，可以依此判斷 Response body的文件類型
Cache-Control: 緩存控制信息，告訴APP端如何緩存該請求

所以一個HTTP請求的耗時其實並不是一個整體，而是可以劃分為多個階段。以Appetizer首頁為例，利用Chrome開發者工具中的Network查看請求用時。

其中 Resource Scheduling 是瀏覽器的事情，APP端沒有； Connection Start 就是連接過程，值得注意的是 Request/Response，分為三段：1. Request Sent: APP發送Request Header + Body的時間；2. Waiting （學名TTFB，Time To First Byte）：指APP接收到Response第一個位元組的時間，一般包括伺服器處理時間以及來回的網路延時； 3. Content Download：就是APP下載完Response Header和Body的總共時間；

Appetizer依此抽象了兩個概念：

Latency包括 Connection Start，Request Sent和 Waiting，其中主要是來回的網路延時（俗稱伺服器ping值）和伺服器處理時間
Transmission Time 即 Content Download，主要是伺服器下行帶寬

Latency 長為什麼，怎麼辦

Latency 長主要是因為網路延時（伺服器ping值）長或者伺服器處理這個介面時間太久，以Appetizer官網為例，這個網站評測了不同地區對Appetizer伺服器的ping值，這個主要是後台運營的問題，解決方法有：

考慮合適的雲服務以及伺服器分布，對部分關切地區加伺服器

新鮮出爐！國內五家最強雲服務商全對比 - 互聯網行業 - 微讀吧

下圖是http://appetizer.io全國訪問的ping值

（好像是廣告位招租）
如果雲服務/自建伺服器的ping值高，那麼建議對部分經常訪問的靜態內容做CDN加速
（好像又是一個廣告位招租）
考慮是否可以對靜態內容cache在APP端

okhttp APP端cache教程

此外，如果伺服器處理時間長，通常就是服務端處理這個介面的響應速度太慢，這個應該交給服務端的同學，通常有以下常見問題：

服務端是否對Session有合適的cache，比如一個已經登錄的用戶是否伺服器已經cache需要的信息在內存

Express 性能調優 - 知乎專欄

如果這個介面主要是資料庫操作，那麼是否對相關的表進行了索引操作

如何優化MongoDB性能？ - 知乎日均數據量千萬級，MySQL、TiDB 兩種存儲方案的落地對比 - 知乎專欄MySQL 慢查詢優化 - 知乎專欄

如果這個介面訪問的是非常通用的內容（比如當天最熱銷的商品列表），服務端是否使用了in-memory caching，例如memcached之類的服務？

如何用redis/memcache做Mysql緩存層? - 知乎

Redis 和 Memcached 各有什麼優缺點，主要的應用場景是什麼樣的？

Transmission Time 長為什麼，怎麼辦

Transmission Time，主要就是APP下載服務端的Response Header和Response Body時間，如果比較慢可以考慮如下問題：

這個介面是否返回了比較大的Response Body（比如圖片, html，JSON），是否考慮

用nginx將返回內容壓縮一下你真的了解 gzip 嗎？ - 知乎專欄

這個介面如果是返回查詢內容，是否考慮增加一個批量查詢功能

系列文章傳送門