【編者按】本文作者是 Nikita Salnikov Tarnovski易稠，是 plumbr 的聯(lián)合創(chuàng)始人缸废，作為一名高級開發(fā)者，他同時也是一位應(yīng)用性能調(diào)優(yōu)的專家缩多，擁有多年的性能調(diào)優(yōu)經(jīng)驗呆奕。本文中他通過常見的性能需求誤區(qū)經(jīng)驗养晋，分享應(yīng)該如何去設(shè)定實際的性能需求目標(biāo)，本文系 OneAPM 工程師編譯呈現(xiàn)梁钾。
以下為譯文：
「這個應(yīng)用跑得太慢绳泉，你能讓它快起來嗎？」
——企業(yè)老板這樣說道
如果你是個經(jīng)驗豐富的工程師姆泻，對這種場景肯定不陌生零酪，一聽到這種話，整個脊椎不寒而栗拇勃。筆者一直強(qiáng)調(diào)用「測量不猜測」的觀點處理性能優(yōu)化問題四苇。這意味著你要先明確經(jīng)理所指的「快」是什么。如果沒有這個定義方咆，你可能永遠(yuǎn)都會困在優(yōu)化周期中月腋，因為每個重大應(yīng)用總能在某些方面得到改進(jìn)，從而提高速度瓣赂。
現(xiàn)實生活中榆骚，性能并非是亟待解決的唯一任務(wù)；為了提供最有價值的產(chǎn)品煌集，我們應(yīng)該知道什么時候應(yīng)該停止性能優(yōu)化妓肢。更重要的是，我們應(yīng)該清楚地知道我們的性能目標(biāo)是什么苫纤，并有一個明確的規(guī)劃去實現(xiàn)之碉钠。
錯誤定義的性能需求
相對之前，企業(yè)老板在表達(dá)軟件功能需求上已經(jīng)有所進(jìn)步卷拘。但在功能性需求之外——比如應(yīng)用的可用性喊废、兼容性或性能——老板心里其實完全沒底。這個空白常常用「確保它夠快」這種模棱兩可的話恭金，或者與下面類似的要求表達(dá)出來：
系統(tǒng)內(nèi)95%的業(yè)務(wù)操作必須在 5 秒內(nèi)得到響應(yīng)
系統(tǒng)必須支持 100 個并發(fā)用戶
乍一看這些要求操禀，你可能會覺得沒那么糟。不再一直念叨著「快快快」横腿，你現(xiàn)在至少有了一個明確的目標(biāo)颓屑，對吧？事實證明耿焊，上面的目標(biāo)甚至比「快快快」的念叨更加糟糕揪惦。雖然它包含了一些可以設(shè)為終極目標(biāo)的具體數(shù)據(jù)；但實際情況下罗侯，上述兩點要求最多只能作為提出更好優(yōu)化問題的基礎(chǔ)器腋。下面解釋這些要求的錯誤之處。
95%的業(yè)務(wù)操作必須在5秒內(nèi)得到響應(yīng)
剩下的五個百分點要怎么辦？如果將響應(yīng)時間設(shè)為10秒纫塌，這個目標(biāo)是否切合實際呢诊县？連接超時也可以嗎？其實措左，你應(yīng)該避免將時間設(shè)定為唯一目標(biāo)依痊，而是設(shè)置一個可接受的延遲分布范圍。這個要求的另一個問題是怎披，它將所有的操作等同化胸嘁。如果有95%的操作在4.9秒內(nèi)反應(yīng)，就萬事大吉了么凉逛？即便這些操作的速度還可以更快性宏？以下面這些操作為例：
- 顯示我當(dāng)前的賬戶余額：這個操作每天被執(zhí)行數(shù)百萬次，也是每個零售客戶與銀行互動的第一個問題状飞。
- 顯示2015年的所有交易：每天僅有少數(shù)用戶執(zhí)行該操作毫胜。
顯然，你需要區(qū)別對待不同的操作昔瞧，對第一個操作有更高要求指蚁，而第二次操作可以有更寬松的要求。因此自晰，你應(yīng)該為每個操作類型設(shè)置可接受的延遲時間分布，而不是對所有操作一視同仁稍坯。
你還應(yīng)該將延遲需求與加載/吞吐量需求聯(lián)系起來酬荞。因此在進(jìn)行性能測量時，應(yīng)該找出系統(tǒng)中的負(fù)載瞧哟，并發(fā)掘有多少其他操作可以同時執(zhí)行混巧。然后用這些信息來構(gòu)建延遲需求。
精確延遲測量的層勤揩。是在終端用戶的環(huán)境中進(jìn)行響應(yīng)時間測量呢 (比如咧党，瀏覽器呈現(xiàn)響應(yīng)時或一個安卓應(yīng)用更新結(jié)果時)？還是當(dāng)最后一個字節(jié)從服務(wù)器端發(fā)送后進(jìn)行測量呢陨亡？
大多數(shù)軟件總是可以優(yōu)化得更快傍衡，問題是它在經(jīng)濟(jì)上是否可行。
最后负蠕，你應(yīng)該確定哪些操作完全不用擔(dān)心延遲蛙埂。批處理作業(yè)和異步流程就是很好的例子。每月運行的批處理任務(wù)需要兩個小時來計算最終的信用卡余額遮糖，不應(yīng)該視為違反了5秒閾值绣的。完整的會計 CSV 報表通過電子郵件發(fā)送得等到10分鐘后，屬于異步編譯，也不應(yīng)該視作違反標(biāo)準(zhǔn)屡江。
系統(tǒng)必須支持100個并發(fā)用戶
設(shè)想一個網(wǎng)站有100個用戶在線芭概，每次點擊靜態(tài)圖像都通過 CDN 進(jìn)行呈現(xiàn)需要10秒時間——我打賭你閉著眼睛就能構(gòu)建出這樣一個系統(tǒng)。但是惩嘉，100個用戶同時在網(wǎng)站上編碼 4K 視頻文件則要另當(dāng)別論了谈山。
當(dāng)考慮真實并發(fā)性時，事情從模糊不清變得毫無意義宏怔，比如將「100個并發(fā)用戶」翻譯成「100次由100個線程并發(fā)處理的操作」奏路。假設(shè)每一個這樣的操作需要10秒的處理時間，那么系統(tǒng)的吞吐量就是每秒10次操作臊诊。如果現(xiàn)在將操作時間減少十倍鸽粉，每個操作只需1秒鐘，你就已經(jīng)將吞吐量提高到100次操作/秒抓艳。然而触机，你并未實現(xiàn) 「100個真實并發(fā)用戶」的要求，只是并發(fā)處理10個操作玷或，這意味著你未能滿足性能要求儡首。
其實，在表達(dá)用戶的具體行為時偏友，應(yīng)該避免「并發(fā)用戶」或任何類似的術(shù)語蔬胯，要求應(yīng)該更加明確，盡量將這些描述轉(zhuǎn)化為可以模擬所需負(fù)載的負(fù)載測試位他。
需要注意氛濒，筆者并非建議你測量吞吐量。這其實沒多大用鹅髓，因為現(xiàn)實生活中的應(yīng)用通常是多功能的舞竿、應(yīng)用于動態(tài)的狀況。所以很難明確表達(dá)出吞吐量的性能目標(biāo)(每小時的操作量)窿冯。但是骗奖，如果一個應(yīng)用被特定設(shè)計為只實現(xiàn)一個功能，例如發(fā)票支付醒串，那么执桌，設(shè)置類似于「1000個發(fā)票/分鐘」的吞吐量目標(biāo)，是非常好的可測量的具體目標(biāo)厦凤。
容量規(guī)劃
容量規(guī)劃是你應(yīng)該精確指定的另一重要性能需求鼻吮。你的團(tuán)隊是有望實現(xiàn)上文提到的目標(biāo)——數(shù)據(jù)庫中容納一萬個帳戶和一千萬個事務(wù)？或者期望系統(tǒng)滿足一百萬個賬戶和十億交易這些條件较鼓？請明確系統(tǒng)中儲存的數(shù)據(jù)量椎木。
別忘了明確有關(guān)基礎(chǔ)設(shè)施的經(jīng)濟(jì)約束违柏。你是否準(zhǔn)備使用價值 500美元/月的 AWS 實現(xiàn)你的性能要求？或者你能財大氣粗地在32核和幾 TBs 容量的高端配置上部署解決方案香椎？知道這些問題的答案可以幫助你了解基礎(chǔ)設(shè)施能承受的性能目標(biāo)漱竖。所以在確定性能需求之前，你應(yīng)該明確基礎(chǔ)設(shè)施的限制畜伐。
在制定性能需求時馍惹，還應(yīng)該考慮客戶的網(wǎng)絡(luò)帶寬限制。網(wǎng)絡(luò)帶寬是否能接受對操作發(fā)送幾個 MBs 來回的要求玛界？移動應(yīng)用固然使用廣泛万矾，但你不能指望每個客戶都使用全能的 4G 網(wǎng)絡(luò)，所以應(yīng)該構(gòu)建一組離線操作慎框，可以在本地進(jìn)行處理良狈，從而將流量從兆字節(jié)轉(zhuǎn)換為千字節(jié)。
結(jié)論
本文所描述的各個方面還不夠完整笨枯。在可伸縮性和可用性方面薪丁，還有許多性能方面的考慮，可以引導(dǎo)你進(jìn)一步完善需求馅精。即便如此严嗜，你應(yīng)該更仔細(xì)地審視模糊的性能需求，列舉出能落實到現(xiàn)實需要的問題洲敢。和企業(yè)老板合作制定可測量的具體目標(biāo)漫玄。否則，你就沒有真正的目標(biāo)去實現(xiàn)并衡量結(jié)果沦疾。
通過這個過程称近，也可以了解相關(guān)的成本。企業(yè)老板總是渴望更詳細(xì)地了解成本哮塞！如果你還記得，大多數(shù)軟件總是可以優(yōu)化得更快凳谦，問題是它在經(jīng)濟(jì)上是否可行忆畅。從企業(yè)所有者的角度來看，他們自然想讓所有操作都盡可能快尸执。但只有當(dāng)我們了解了實現(xiàn)目標(biāo)的成本限制家凯，才能設(shè)置更為現(xiàn)實的期望。
OneAPM 是應(yīng)用性能管理領(lǐng)域的新興領(lǐng)軍企業(yè)如失，能幫助企業(yè)用戶和開發(fā)者輕松實現(xiàn)：緩慢的程序代碼和 SQL 語句的實時抓取绊诲。想閱讀更多技術(shù)文章，請訪問 OneAPM 官方博客褪贵。
本文轉(zhuǎn)自 OneAPM 官方博客
