如何進行測試？
我經常遇到一些開發團隊，他們收到諸如“客戶端將每小時處理20個客戶”此類的性能需求。團隊就試圖把該需求轉化為某種測試。執行這種測試的常見方法就是以死循環的形式對服務器進行反復請求，然后靜觀其效。通常事情進行得不是很順利，這就是為什么隨后我會作為一個性能專業化方面的顧問“遇見他們”的原因。通常我問的第一個問題是：“您是如何進行測試的？”一般來說，答案會是：“我們將請求置于循環中，然后計算服務器可以處理的請求的數目�！闭沁@種回答使我明白首先要做的就是調整軟件測試工具本身。
如果您不明白上述測試有什么問題，不要擔心——有很多人和您一樣。進行一次切實可行的壓力測試并不像乍看之下那么簡單。遇到的問題可能非常微妙，而且通常只有采用不那么簡單的方法來理清情況才能看清問題。但是這并不是讓您目光呆滯地深入研究馬爾可夫鏈(Markov chains)、狀態改變模型、排隊理論、概率分布等等，讓我們以一種不那么乏味的、更通俗易懂的方式來說明如何解決這個在許多壓力測試中出現的常見問題。
測試方式將影響測試
我們首先要明白的是，雖然測試通常都是從客戶端活動的角度定義的，但是它們必須從以服務器為中心的視角來看待。以服務器為視角將只看到客戶端訪問的頻率和處理每個請求所花費的時間。讓我們考慮一個典型例子，即銀行的出納員。出納員通常不知道您是什么時候到的，也不知道您是從哪里來的。他們所知道的只是您在這里，而且您要讓他們為您做一些事情�，F在，隊列中有多少人將取決于人們到達的速度，以及滿足他們的要求所花的時間。
比隊列中有多少人更重要的是，隨著后來的人不斷補進隊列，房間中的人數是在減少、保持不變還是在增加？與之相隨的另一個問題是，人們進入隊列的速度與離開的速度相比，是快一些、相同還是慢一些？如果離開的速度要比到達的速度快，那么處理請求的速度要比遞交請求的速度快。第二種情況說明剛剛處理完一個客戶，下一個就到達了。最后一種情況則說明人們到達的速度要比處理的速度快。用數學術語來說，第一種系統是收斂的，第二種處于穩定狀態，第三種則是發散的。這三種情況中房間中的人數都是由利托氏定理(Little's Law)決定的。
只做力所能及的
對于外行來說，利托氏定理說明了您只能做這么多工作。其數學版本是這么說的：系統中的請求數等于請求到達的速度乘以它們在系統中的時間所產生的積。如果它們在系統中的時間取決于流出系統的速度（通常稱為服務時間），那么就可以通過觀察請求到達的頻率（請求到達間隔時間）并與服務時間比較，而確定系統處于哪種狀態。
對于每種情況，利托氏定理都描述了系統是如何處理工作負載的。雖然狀態可能會發生瞬時的迸發和間歇，總體的趨勢還將由平均的狀況決定。例如，在收斂系統中，可能會由于許多人同時進入隊列而產生瞬時的暴漲，但是隊列仍將會騰空，因為收斂系統的傾向就是趨向空閑。但是，第三種場景是發散的，其中的請求數將會無限增長。它會嗎？這個問題的答案與如何定義發出請求的全域有關。
在某個隨機的時間點，全域中的用戶將發出一個請求。這肯定是從以服務器為中心的視角來看全域了。大多數系統都基于一個假設，即在任一個給定的時間點，全域中只有一部分會發出請求。經驗告訴我們，在許多因特網應用程序中，全域中有10％在任意時間點都是活動的。我們需要知道這種信息，如果我們要定義實際的壓力測試的話。例如，如果全域中有1000個用戶，我們會預料有100個每時每刻都在使用系統。由于我們估計會有10％的并發使用，用戶庫又有 1000個用戶，所有我們的測試應該模擬100個用戶重復執行一些請求系列。用這種方法定義測試的危害是它反映的是客戶端的視角。
當我們從以服務器為中心的視角轉向以客戶端為中心的視角后，就看不到向服務器發送請求的速度了。如果我們限制或固定為執行用戶請求所分配的用戶（線程）數目，那么就看得更模糊了。在這種情況下進行測試，我們將看到服務器正在處理穩定的請求流，而處理請求的時間似乎越來越長。
每個人都可以參與
如果我們讓模擬線程盡可能快地發出請求，就是在模擬整個全域（甚至更多）的用戶都在同一時間發出請求。我們假定服務器模型為單一的，因為這樣便于理解；多服務器模型的工作方式是相同的，只是更快一些。系統將把請求排隊，并且每次只處理一個。一旦有一個請求清除，線程會立即返回隊列頭部發出下一個請求。雖然這種事件順序似乎說明我們處理的是一個穩定狀態的系統，但我們實際上是在處理發散系統。它之所以看起來像穩定狀態系統的惟一原因是，我們限制了發出請求的線程數目。正如前面所提到的，在發散系統中，每個后繼用戶的響應時間都要比前一個所經歷的時間長。這意味著平均響應時間將不斷地增長而沒有限制。盡管如此，但是我們人為地限制了客戶端的數目，因此平均響應時間將穩定在一個點上，該點取決于客戶端數目與處理單個請求所花費時間的乘積。這里所說的這種系統中的響應時間包括花在隊列中的時間，而且因為花在隊列中的時間比預料的要少，所以我們又人為擴大了測量值。最終結果是您的測試限制了您確定系統的可伸縮性的能力。
如何修復
要修復壓力測試，需要知道用戶/線程發出請求的速度。所有用戶的速度之和就轉化為服務器接受請求的速度。一旦確定了這個值，就可以對工具發出請求的速度進行調整。下面的表列出了幾個可以用來維持50個請求每秒(RPS)的值。從服務器的視角來看，工具需要每20ms提供一個請求。這種觀點反映的是單個線程的情況。如果工具配置了兩個線程，那么對于每個線程，都應該維持40ms的請求間時間間隔。表中還列出了使用5個線程和10個線程的情況下的時間間隔。
線程數目 線程頻率 請求間時間間隔(inter-request interval) 1 50/sec 20ms 2 25/sec 40ms 5 10/sec 100ms 10 5/sec 200ms
文章來源于領測軟件測試網 http://www.kjueaiud.com/