Web 應用設計最重要的一個體驗就是響應速度，而響應速度的第一步就是速度，但影響一個 Web 應用的速度是多因素的。

為了保持 Github 訪問快速，我們的策略是通過內部強大的工具來揭示和解釋各種性能指標。通過這些指標數據，我們可更輕松的理解復雜的產品環境以及如何解決系統中的性能瓶頸，保證 Github 訪問快速。

性能儀表板

響應時間是一個平均值，一般對一個復雜的應用來說意義不大。但什么數字是有用的呢？性能儀表板試圖對合格問題給予一些有用的答案，通過 Graphite 獲得的數據，可顯示 Github.com 整站的響應時間概覽。

我們將響應時間分為兩種，分別是：

• Browser - 登錄用戶通過瀏覽器對頁面的加載
• Public - 未登錄用戶訪問頁面

點擊上面數據其中一列可進入查看詳情。

性能儀表板可顯示性能信息，但無法解釋為什么會這樣，因此我們需要一些更詳細的數據。

任務控制欄

GitHub 的員工可以使用 staff 模式來瀏覽網站，這個模式通過一個鍵盤快捷鍵來激活，可以只訪問 staff 模式專有的功能，包括“任務控制欄”，當該欄顯示出來，可通過它來調整網站，如果它隱藏掉，那跟一個普通的用戶訪問沒有區別。

劇透：你可能會注意到下面界面跟你平時所看到的有所不同。

左邊顯示了當前發布的分支以及此頁面執行和渲染所用的時間，如果使用 Chrome 瀏覽器，我們會顯示各種不同的時間耗費情況，這個數據用來診斷頁面的響應時間非常有幫助，你可看出網頁訪問慢的根源所在，是網絡、是瀏覽器還是應用程序。

而右側則是不同的應用指標，我們顯示了當前壓縮的 JS 和 CSS 大小、后臺作業隊列以及不同的數據源時間，包括：

• render – 該頁面在服務器上的生成時間
• cache – memcached calls.
• sql – MySQL calls.
• git – Grit calls.
• jobs – 當前后臺作業隊列

當我們準備好一個頁面，我們可通過點擊這些數值來查看詳情，我們會通過 rack-bug 和 query-reviewer 來劫持各種特性以便生成這些數據。

更多...

我們還用了很多其他工具，例如 New Relic, Graphite, 以及一些老式的 Unix 工具來幫忙分析性能問題。

在這篇文章中有很多的數字比我想的要慢得多，但我們希望提供更好的透明度，以便我們能夠提供最快的Web應用程序。

正如 @tnm 所說的：it’s not fully shipped until it’s fast.

原文鏈接：https://github.com/blog/1252-how-we-keep-github-fast（OSCHINA原創翻譯）