設(shè)置 JMeter

JMeter 是一個(gè)功能強(qiáng)大的開(kāi)源 Java 應(yīng)用程序，具有多種功能，這使得在其中設(shè)置測(cè)試計(jì)劃令人望而生畏。在瀏覽有關(guān)該主題的文檔時(shí)，我在Drupal 性能測(cè)試套件頁(yè)面上找到了一個(gè)特定于 Drupal 的示例 JMeter 計(jì)劃。該計(jì)劃附帶設(shè)置了 HTTP 請(qǐng)求、標(biāo)頭和偵聽(tīng)器元素。下圖顯示了計(jì)劃文檔的外觀。

以下是使用它之前需要做的一些自定義：

激活與您的 Drupal 版本對(duì)應(yīng)的用戶定義變量元素;停用另一個(gè)。

將主機(jī)變量設(shè)置為您要測(cè)試的服務(wù)器的主機(jī)名。

在兩個(gè)線程組中，設(shè)置線程數(shù)。這是您希望模擬的并發(fā)用戶數(shù)。

在兩個(gè)線程組中，設(shè)置Loop Count。這個(gè)數(shù)字將決定每個(gè)線程運(yùn)行多少次，從而控制測(cè)試的長(zhǎng)度。如果您想了解服務(wù)器在恒定負(fù)載下的性能，請(qǐng)針對(duì)一分鐘的測(cè)試。第二長(zhǎng)的測(cè)試可能不會(huì)產(chǎn)生相關(guān)的結(jié)果，因?yàn)榉?wù)器可能需要一些時(shí)間在負(fù)載變化的情況下穩(wěn)定下來(lái)——例如，需要?jiǎng)?chuàng)建新的服務(wù)器線程。如果您有目標(biāo)時(shí)間和吞吐量的近似值(服務(wù)器在一秒鐘內(nèi)可以處理的請(qǐng)求數(shù))，則可以使用以下公式計(jì)算循環(huán)計(jì)數(shù)：

循環(huán)計(jì)數(shù) = 吞吐量 * 時(shí)間 / 線程數(shù)。

修改、添加或刪除 HTTP 請(qǐng)求元素，以便它們反映您希望隨請(qǐng)求獲取的頁(yè)面。

可以在HTTP 標(biāo)頭管理器元素中調(diào)整Keep-alive和Accept-Encoding標(biāo)頭，盡管在大多數(shù)瀏覽器中通常會(huì)發(fā)現(xiàn) keep-alive 和壓縮啟用，因此保持它們不變應(yīng)該沒(méi)問(wèn)題。

在windows上試用后發(fā)現(xiàn)JMeter占用了很多內(nèi)存，最終會(huì)拋出java.lang.OutOfMemoryError: GC overhead limit exceeded錯(cuò)誤?？梢酝ㄟ^(guò)在 jmeter.bat 中設(shè)置內(nèi)存限制來(lái)緩解該問(wèn)題。將限制設(shè)置為 512MB，它能夠運(yùn)行大約 3100 個(gè)請(qǐng)求。雖然我沒(méi)有超過(guò)這個(gè)數(shù)字，但我仍然增加了內(nèi)存限制，以便它在接近這個(gè)數(shù)字并填滿內(nèi)存時(shí)不會(huì)影響速度。

準(zhǔn)備數(shù)據(jù)

為了了解我應(yīng)該模擬多少并發(fā)用戶，我檢查了站點(diǎn)統(tǒng)計(jì)信息。網(wǎng)站的所有者組織活動(dòng)，這往往會(huì)比平時(shí)吸引更多的訪問(wèn)者訪問(wèn)網(wǎng)站。因此，服務(wù)器負(fù)載偶爾會(huì)出現(xiàn)峰值，如下圖所示。

2010 年 5 月 1 日至 2011 年 5 月 1 日之間的訪客。訪客總數(shù)：3,835,880

為了了解服務(wù)器如何處理不斷增加的流量，我想在并發(fā)用戶數(shù)量逐漸增加的情況下運(yùn)行多個(gè)測(cè)試。我選擇了最小的數(shù)字來(lái)開(kāi)始測(cè)試，即基于一個(gè)月的數(shù)據(jù)的平均并發(fā)訪問(wèn)者數(shù)。當(dāng)然，這并不能告訴我們太多關(guān)于任何給定時(shí)刻的實(shí)際負(fù)載，但它給出了服務(wù)器不斷受到的壓力基線。下圖顯示了用于計(jì)算平均并發(fā)訪問(wèn)者數(shù)的數(shù)據(jù)。

2011 年 4 月 1 日至 2011 年 4 月 30 日期間的

訪問(wèn)者總訪問(wèn)者：366,975

總瀏覽量：937,643

平均?，F(xiàn)場(chǎng)時(shí)間：87秒

我們?cè)?Google Analytics 中隨時(shí)可用的數(shù)據(jù)是訪問(wèn)者數(shù)量和平均訪問(wèn)時(shí)長(zhǎng)。根據(jù)這些數(shù)字，可以使用以下公式計(jì)算并發(fā)用戶數(shù)：

并發(fā)用戶數(shù) = 訪問(wèn)者率 * 訪問(wèn)時(shí)間

因?yàn)槲覀冇幸悦霝閱挝坏脑L問(wèn)時(shí)長(zhǎng)，所以我們還需要將每月訪問(wèn)者的數(shù)量投影到秒。

訪客率 = 366,975 訪客/(30 天 * 24 小時(shí) * 60 分鐘 * 60 秒)= 0.1415 訪客/秒

這使

并發(fā)用戶數(shù) = (0.1415 訪問(wèn)者/秒) * 87 秒 = 13 訪問(wèn)者

第二個(gè)測(cè)試周期基于對(duì)應(yīng)于最近峰值的數(shù)據(jù)。這顯示了服務(wù)器將來(lái)肯定會(huì)遇到的流量。我選擇了 3/11 的峰值，這是今年數(shù)據(jù)中最大的峰值。下圖顯示了 3 月 11 日訪客的每小時(shí)圖表。

2011 年 3 月 11 日峰值的小時(shí)圖。

上午 9 點(diǎn)高峰期的訪客：上午 9 點(diǎn)高峰期的 1,570 次

瀏覽量：

平均5,328 次。現(xiàn)場(chǎng)時(shí)間：108秒

上午 9 點(diǎn)高峰的訪客人數(shù)為 1570。應(yīng)用之前使用的公式，我們得到

訪客率 = 1,570 訪客 / 60 分鐘 / 60 秒 = 0.4361 訪客 / 秒

并發(fā)用戶數(shù) = (0. 4361 訪問(wèn)者/秒) * 108 秒 = 48 訪問(wèn)者

最后，在第三輪測(cè)試中，我想保持安全，并提出一個(gè)超過(guò)任何預(yù)期激增的數(shù)字。有理由認(rèn)為，目前最大峰值兩倍的負(fù)載將是一個(gè)極端事件，并且在正常運(yùn)行期間不太可能發(fā)生(或者至少會(huì)有一些警告信號(hào))。因此，我在最后一輪測(cè)試中將訪問(wèn)者參數(shù)設(shè)置為 100。

這給了我 13、48 和 100 個(gè)并發(fā)訪問(wèn)者來(lái)測(cè)試。接下來(lái)，我必須決定應(yīng)該針對(duì)哪些頁(yè)面運(yùn)行測(cè)試。無(wú)論我選擇什么都是不現(xiàn)實(shí)的，因?yàn)閿?shù)百名訪問(wèn)者不太可能點(diǎn)擊相同的幾個(gè)頁(yè)面。我認(rèn)為我能做的最好的事情就是針對(duì)最常訪問(wèn)的頁(yè)面運(yùn)行測(cè)試。這樣，測(cè)試請(qǐng)求與現(xiàn)實(shí)生活中的大部分請(qǐng)求重疊。

我正在測(cè)試的站點(diǎn)上訪問(wèn)量最大的頁(yè)面是主頁(yè)，其中包含多個(gè) Drupal 視圖。還有一個(gè)頁(yè)面有很多入站鏈接，并且比所有其他頁(yè)面更頻繁地被請(qǐng)求;我也包括在內(nèi)。我測(cè)試的第三個(gè)頁(yè)面是 Drupal 節(jié)點(diǎn)頁(yè)面。節(jié)點(diǎn)頁(yè)面在結(jié)構(gòu)上非常相似，并且構(gòu)成了絕大多數(shù)頁(yè)面。我將這些頁(yè)面分別稱為 Homepage、Landing Page 和 Node。

運(yùn)行測(cè)試

負(fù)載是在與服務(wù)器分開(kāi)的網(wǎng)絡(luò)中的單獨(dú)計(jì)算機(jī)上生成的。這樣，測(cè)試結(jié)果包括當(dāng)有人請(qǐng)求頁(yè)面時(shí)發(fā)揮作用的所有因素，包括網(wǎng)絡(luò)延遲和頁(yè)面呈現(xiàn)時(shí)間。此外，如果負(fù)載是在為頁(yè)面提供服務(wù)的同一臺(tái)機(jī)器上生成的，負(fù)載生成器會(huì)占用服務(wù)器的一些資源，從而影響結(jié)果。

在測(cè)試期間，我使用top命令監(jiān)控服務(wù)器負(fù)載。我注意到在測(cè)試結(jié)束時(shí)讀取的 1 分鐘平均值。因?yàn)樗袦y(cè)試的運(yùn)行時(shí)間都超過(guò) 1 分鐘，所以平均值中的所有數(shù)據(jù)都被測(cè)試負(fù)載覆蓋。測(cè)試結(jié)果是從測(cè)試計(jì)劃的摘要報(bào)告元素中獲取的。我多次運(yùn)行測(cè)試并獲得了我能夠重現(xiàn)的結(jié)果。

站點(diǎn)上啟用了 Drupal 頁(yè)面緩存。沒(méi)有可用的公開(kāi)注冊(cè);只有組織的員工才有用戶帳戶;大部分流量來(lái)自匿名用戶。

測(cè)試結(jié)果如下：

13個(gè)并發(fā)訪問(wèn)者，100個(gè)循環(huán)

負(fù)載：0.56

48個(gè)并發(fā)訪問(wèn)者，60個(gè)循環(huán)

負(fù)載：0.79

100個(gè)并發(fā)訪問(wèn)者，30個(gè)循環(huán)

負(fù)載：0.9

最后，我對(duì)經(jīng)過(guò)身份驗(yàn)證的用戶進(jìn)行了一項(xiàng)測(cè)試，以便將服務(wù)匿名用戶的性能與服務(wù)經(jīng)過(guò)身份驗(yàn)證的用戶的性能進(jìn)行比較。

13 個(gè)并發(fā)訪問(wèn)者，30 個(gè)循環(huán)，經(jīng)過(guò)身份驗(yàn)證的用戶

加載 14.51

(登錄頁(yè)面的行沒(méi)有顯示)

結(jié)論和見(jiàn)解

引人注目的第一件事是，經(jīng)過(guò)身份驗(yàn)證的用戶的吞吐量是匿名用戶的 1/7。這源于站點(diǎn)上啟用了 Drupal 頁(yè)面緩存，并且匿名用戶從緩存中提供服務(wù)，而頁(yè)面為經(jīng)過(guò)身份驗(yàn)證的用戶的每個(gè)頁(yè)面加載重新生成。該測(cè)試還將服務(wù)器負(fù)載增加到 14.51，這表明有點(diǎn)過(guò)載?？紤]到該服務(wù)器采用 4 核 Intel Xeon L5420 處理器，服務(wù)器負(fù)載不應(yīng)長(zhǎng)時(shí)間保持在 4 以上，因?yàn)檫@意味著 4 核的充分利用。對(duì)于匿名用戶，對(duì)于多達(dá) 100 個(gè)并發(fā)訪問(wèn)者來(lái)說(shuō)，它并沒(méi)有接近過(guò)載。

接下來(lái)我注意到的是首頁(yè)的加載速度比其他頁(yè)面慢得多。這是一個(gè)意料之外的結(jié)果，因?yàn)槿绻麊⒂昧隧?yè)面緩存，那么所有頁(yè)面都應(yīng)該從緩存中提供，在這種情況下，我看不出首頁(yè)可能會(huì)慢得多的任何原因。這可能需要我進(jìn)一步調(diào)查。

可以與 Analytics 中可用數(shù)據(jù)進(jìn)行比較的一項(xiàng)測(cè)試結(jié)果是吞吐量。根據(jù)頁(yè)面瀏覽量，可以計(jì)算出為給定數(shù)量的請(qǐng)求提供服務(wù)所需的吞吐量。我使用了上圖中峰值的數(shù)據(jù)作為比較的基礎(chǔ)。應(yīng)用公式Number of Pageviews / Length of Time Interval = Throughput，我們得到

5,328 個(gè)請(qǐng)求/(60 分鐘 * 60 秒)= 1.45 個(gè)請(qǐng)求/秒

這遠(yuǎn)低于為多達(dá) 100 個(gè)并發(fā)匿名訪問(wèn)者測(cè)量的容量。對(duì)于經(jīng)過(guò)身份驗(yàn)證的用戶，這將非常接近服務(wù)器實(shí)際可以服務(wù)的速率。如果網(wǎng)站決定開(kāi)放注冊(cè)并鼓勵(lì)用戶登錄，則應(yīng)考慮到這一點(diǎn)。

重要的是要注意并發(fā)用戶和瀏覽量之間的因素 - 或平均瀏覽量，正如 Analytics 所說(shuō)的 - 會(huì)有所不同。與另一站點(diǎn)上的大量訪問(wèn)者相比，少數(shù)并發(fā)訪問(wèn)者可以在一個(gè)站點(diǎn)上發(fā)起更多請(qǐng)求。出于這個(gè)原因，知道服務(wù)器可以處理給定數(shù)量的并發(fā)訪問(wèn)者可能不夠，也可能不夠，具體取決于這些訪問(wèn)者產(chǎn)生的網(wǎng)頁(yè)瀏覽量。如果您想了解更多相關(guān)知識(shí)，可以關(guān)注一下動(dòng)力節(jié)點(diǎn)的Java在線學(xué)習(xí)，里面的課程由淺到深，適合沒(méi)有基礎(chǔ)的小伙伴學(xué)習(xí)，希望對(duì)大家能夠有所幫助。