在程序員面試中，有一個非常經典的問題，你們的系統性能怎么樣?你是怎么得到這個結果的。不知道你有沒有遇到過?？赡芎芏嗳硕家呀浿廊绾稳ズ饬孔约合到y的性能，但卻敵不住面試官的第二個問題，如何得到這個結果。很多人都會說壓測，那么在壓測過程中，有我們會遇到哪些問題呢，有沒有一些問題會造成我們測試結果錯誤。

[[322318]]

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

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

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

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

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