架構師視角也就是從系統的全鏈路視角，來分析系統性能指標
一次請求鏈路圖
步驟一：DNS解析，，使用者在瀏覽器輸入URL按回車，請求會進行DNS查詢，瀏覽器透過DNS解析查到域名對映的IP地址，查詢成功後，瀏覽器會和該IP地址建立連線。對應的效能指標為：DNS解析時間。對於這個指標，我們可以透過DNS快取或DNS預解析，適當增大域名的TTL值來增大DNS伺服器快取域名的時間，進而提升了快取的命中率。也可以用dns-prefetch標籤實現域名的預解析，讓瀏覽器在後臺把要用的DNS請求提前解析，當用戶訪問的頁面中包含了預解析的域名時，再次解析DNS就不會有延遲了。
步驟二：建立TCP連線，由於HTTP是應用層協議，TCP是傳輸層協議，所以HTTP是基於TCP協議基礎上進行資料傳輸的，所以你要建立TCP請求連線，這裡也可以用TCP的連線時間來衡量瀏覽器與Web伺服器建立的請求連線時間。
步驟三：伺服器響應
這部分是一個最重要的新能指標，即伺服器端的延遲和吞吐能力，針對影響服務端效能的指標，還可以細分為基礎設施效能指標、資料庫效能指標，以及系統應用效能指標。
基礎設施效能指標主要針對CPU利用率、磁碟I/O，網路頻寬、記憶體利用率。例如，CPU佔用率超過80%，就很有可能是系統出了問題。如果記憶體利用率達到100%，可能是應為記憶體中存放了快取，因此還要衡量SWAP交換空間的利用率，另外，還要考慮容器的 JVM 的Full GC 情況、磁碟 I/O 是否可以最佳化、網路頻寬是否存在瓶頸等問題都會影響系統的最終效能。
資料庫的效能指標主要有 SQL 查詢時間、併發數、連線數、快取命中率等。
系統應用效能指標和系統業務有關，因為業務場景影響架構設計，比如To C 的系統一般會設計成同步 RPC 呼叫，因為要實時反饋 C 端使用者的請求，而 To B 的系統則可以設計成事件驅動模式，透過非同步通知的方式，推送或拉取資料，兩種架構對比，顯然非同步事件驅動的吞吐量會更高。
步驟四：白屏時間
當瀏覽器與 Web 伺服器建立連線後，就可以進行資料通訊了。Web 伺服器接收請求後，開始處理請求，瀏覽器這時會等待Web 伺服器的處理響應。
由於瀏覽器自上而下顯示 HTML，同時渲染順序也是自上而下的，所以當用戶在瀏覽器位址列輸入 URL 按回車，到他看到網頁的第一個視覺標誌為止，這段白屏時間可以作為一個性能的衡量指標（白屏時間越長，使用者體驗越差）。
最佳化手段為減少首次檔案的載入體積，比如用 gzip 演算法壓縮資原始檔，調整使用者介面的瀏覽行為（現在主流的Feed流也是一種減少白屏時間的方案）。
步驟五：首屏時間
使用者端瀏覽介面的渲染，首屏時間也是一個重要的衡量指標，首屏時間是指：使用者在瀏覽器地址輸入 URL 按回車，然後看到當前視窗的區域顯示完整頁面的時間。一般情況下，一個頁面總的白屏時間在 2 秒以內，使用者會認為系統響應快，2 ~ 5 秒，使用者會覺得響應慢，超過 5 秒很可能造成使用者流失。
如何分析系統的效能瓶頸？
設計階段，定義系統性能目標
要在專案初期定義好系統大致的效能目標，比如希望單臺伺服器能夠負載多少 TPS 的請求，因為不同的效能會影響到系統的架構設計，也會帶來不同的成本，一旦過了設計階段，再因為效能問題調整系統架構，成本極高。比如，當前單機效能是 80 TPS，要想最佳化到100 TPS，可以做一些小的效能最佳化，但要提升到 1000 TPS，就要進行架構改造了，代價非常大。
開發階段，走查程式碼和業務流程
也就是評審程式碼，程式碼包括應用程式原始碼、環境引數配置、程式整個呼叫流程和處理邏輯。例如，使用者在 App 中觸發了“立即下單”按鈕，服務端的應用程式從執行緒池裡取得了執行緒來處理請求，然後查詢了幾次快取和資料庫，都讀取和寫入了什麼資料，再把最終的響應返回給 App，響應的資料報文格式是什麼，有哪些狀態碼和異常值……
測試階段，壓測發現系統性能峰值
一般來說，要在系統上線前，對系統進行全方位的壓力測試，繪製出系統吞吐量和延遲曲線，然後找到最佳效能點，並在超過最佳效能點時做限流，如果達不到最佳效能點（比如多數系統的吞吐量，隨著壓力增大，吞吐量上不去）就需要考慮出現延遲和吞吐量的這幾種情況。
1.定位延遲問題
要本著端到端的策略，大到整體流程，小到系統模組呼叫，逐一排查時間消耗在哪裡。
可以使用 kill -3 PID， jstack 等命令列印系統當前的執行緒執行的堆疊；還可以用一些效能分析工具，如 JProfiler 來監控系統的記憶體使用情況、垃圾回收、執行緒執行狀況，比如發現了執行的 100 個執行緒裡面，有 80 個卡在某一個鎖的釋放上面，這時極有可能這把鎖造成的延遲問題。
2. 對於吞吐量問題的定位
對於吞吐量指標要和 CPU使用率一起來看，在請求速率逐步增大時，經常會出現四種情況：