Web 應(yīng)用設(shè)計(jì)最重要的一個(gè)體驗(yàn)就是響應(yīng)速度，而響應(yīng)速度的第一步就是速度，但影響一個(gè) Web 應(yīng)用的速度是多因素的。

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

性能儀表板

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

我們將響應(yīng)時(shí)間分為兩種，分別是：

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

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

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

任務(wù)控制欄

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

劇透：你可能會(huì)注意到下面界面跟你平時(shí)所看到的有所不同。

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

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

• render – 該頁面在服務(wù)器上的生成時(shí)間
• cache – memcached calls.
• sql – MySQL calls.
• git – Grit calls.
• jobs – 當(dāng)前后臺(tái)作業(yè)隊(duì)列

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

更多...

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

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

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

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