在程序員面試中，有一個非常經(jīng)典的問題，你們的系統(tǒng)性能怎么樣?你是怎么得到這個結果的。不知道你有沒有遇到過。可能很多人都已經(jīng)知道如何去衡量自己系統(tǒng)的性能，但卻敵不住面試官的第二個問題，如何得到這個結果。很多人都會說壓測，那么在壓測過程中，有我們會遇到哪些問題呢，有沒有一些問題會造成我們測試結果錯誤。

[[322318]]

首先是壓測的時候的數(shù)據(jù)樣本問題。很多人在壓測，為了尋求方便，喜歡使用同一賬號，或者請求相同的數(shù)據(jù)。這個是不對的，即便是你的業(yè)務代碼沒有做緩存，當是你使用到的很多組件，例如數(shù)據(jù)庫等，都有一定的緩存，所以，這樣測試的結果，數(shù)據(jù)往往是偏好的。而有的人，往往走向了另外一個極端，雖然說用戶的訪問情況我們無法控制，但是，大部分的互聯(lián)網(wǎng)請求都滿足28原則，即20%的用戶占了80%的流量，有些人在壓測的時候，往往沒有注意到這樣的情況，這樣容易造成熱點數(shù)據(jù)丟失，系統(tǒng)的大部分緩存無法生效，導致測試數(shù)據(jù)錯誤。

所以，當我們做系統(tǒng)壓測的時候，盡量去構造更多的數(shù)據(jù)樣本，避免壓測數(shù)據(jù)與線上數(shù)據(jù)失真太嚴重，一般在大公司，這些測試數(shù)據(jù)都有專門的工程師進行維護，例如在阿里，會把現(xiàn)網(wǎng)用戶的數(shù)據(jù)，然后把脫敏后的數(shù)據(jù)變成后期壓測的數(shù)據(jù)。

不知道你有沒有這樣的經(jīng)歷，壓測的時候到了一定的壓力的時候，系統(tǒng)看起來已經(jīng)達到了一定的瓶頸。這個時候直接大幅提升流量，發(fā)現(xiàn)系統(tǒng)的吞吐也猛增上去，看起來很不科學。之前我們已經(jīng)提到過，不談準確率的壓測是毫無意義的。如果一個系統(tǒng)的錯誤率過高，這個時候多大的吞吐量意義并不是很大。在上述例子中，很有可能是因為觸發(fā)了系統(tǒng)過載保護，直接對請求進行快速拒絕，從而給我們系統(tǒng)的吞吐大大提升的錯覺。我們在壓測的時候，一定要對系統(tǒng)返回數(shù)據(jù)的準確性進行校驗，只有正確的返回才有意義。

另外一個重要的事情則是壓測的時間不宜過短，有些同學害怕壓測的時候影響下游系統(tǒng)，每次都是偷偷摸摸地開啟一會就立馬關閉，這個時候得到的壓測數(shù)據(jù)意義并不是很大，我以前在阿里參加雙十一全鏈路壓測的時候，幾乎每一輪最少都要持續(xù)30分鐘。有些系統(tǒng)是需要預熱的，例如一些緩存，只有達到閾值才會進入緩存，有些系統(tǒng)則是可能存在一些內存泄露問題，可能需要隨著時間的進行才會逐漸暴露出來，有些是要到FullGC等出現(xiàn)才會有嚴重的性能問題，一般來說，我們壓測的時候，要等到數(shù)據(jù)平穩(wěn)之后，再持續(xù)觀察一段時間，少則半個小時，像一些底層組件的基礎測試，甚至需要1,2天。

好了，今天我們就分享到這里，不知道你對自己的系統(tǒng)是否有一些反思呢，希望對你有所幫助。