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

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

性能儀表板

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

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

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

點擊上面數(shù)據(jù)其中一列可進入查看詳情。

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

任務控制欄

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

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

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

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

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

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

更多...

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

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

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

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