基于apache的web服務(wù)器性能優(yōu)化和分析(編輯修改稿)
2024-12-16 16:08 本頁(yè)面
【文章內(nèi)容簡(jiǎn)介】 入了定時(shí)器元件—— “Gaussian Random timer” 。執(zhí)行該操作之后，客戶端的請(qǐng)求的分布更加混亂，將會(huì)以隨機(jī)方式而不是以相等的時(shí)間間隔來(lái)點(diǎn)擊服務(wù)器。我們將 Gaussian隨機(jī)時(shí)間設(shè)置為偏離100ms，恒定延遲偏移量為 300ms. 運(yùn)行負(fù)載測(cè)試 用戶可以通過(guò)單擊 Ctrl+R運(yùn)行負(fù)載測(cè)試，或者從菜單中選擇 Run并單擊 Start運(yùn)行負(fù)載測(cè)試。單擊圖形元件，將會(huì)看到圖表被填充，數(shù)據(jù)代表對(duì)服務(wù)器的請(qǐng)求，如圖 4至 6所示。 圖 4：說(shuō)明測(cè)試結(jié)果的圖表。線 程數(shù)＝ 5，等候時(shí)間＝ 10，循環(huán)數(shù)＝ 100。循環(huán)控制器設(shè)置為 1。 我們選擇在圖表中顯示三個(gè)參數(shù) —— 吞吐量（綠線）、中間值（紫線）和平均值（藍(lán)線）。我們對(duì)測(cè)試參數(shù)進(jìn)行修改。為了模擬服務(wù)器上的較高負(fù)載，我們將線程數(shù)提高到 10和 50并比較服務(wù)器的響應(yīng)時(shí)間。再次單擊 Start并觀查圖表中顯示的結(jié)果；參見(jiàn)圖 5和圖 6。 圖 5：說(shuō)明測(cè)試結(jié)果的圖表。線程數(shù)＝ 50，等候時(shí)間＝ 5，循環(huán)數(shù)＝ 20，循環(huán)控制器設(shè)置為 1。 圖表底部參數(shù)的含義如下： 吞吐量是服務(wù)器每分鐘處理的請(qǐng)求數(shù)。 平均值是總運(yùn)行時(shí)間除以發(fā)送到服務(wù)器的請(qǐng)求數(shù)。 中間值是代表時(shí)間的數(shù)字，有一半的服務(wù)器響應(yīng)時(shí)間低于該值而另一半高于該值。 偏離表示服務(wù)器響應(yīng)時(shí)間變化、離散程度測(cè)量值的大小，或者，換句話說(shuō)，就是數(shù)據(jù)的分布。 最后的樣本就是最后完成的請(qǐng)求。 只要觀察這三次運(yùn)行及它們的相應(yīng)圖表，我們就可 以得到下列有價(jià)值的結(jié)果： 響應(yīng)時(shí)間很明顯地隨著線程的增加而增加。若要繼續(xù)進(jìn)行測(cè)試，我們可以更改線程數(shù)、等候周期和循環(huán)數(shù)。注意：我們沒(méi)有更改或調(diào)整服務(wù)器的配置。 WebLogic Server 一個(gè)可自動(dòng)配置的線程池，其配置范圍受到限制（請(qǐng)參閱 Naresh Revanuru撰寫(xiě)的 Workload Management in WebLogic Server ， Dev2Dev），上表說(shuō)明客戶端數(shù)量的增長(zhǎng)對(duì)服務(wù)器響應(yīng)時(shí)間的影響是非線性的。實(shí)際上，將這個(gè)數(shù)字提高兩倍或十倍不會(huì)產(chǎn)生明顯的影響！然而，使用接近或超過(guò)默認(rèn)服務(wù)器限制的線程數(shù)來(lái)運(yùn)行同一個(gè)試驗(yàn)時(shí)應(yīng)引起注意。為了檢驗(yàn)從服務(wù)器收到的響應(yīng)是真實(shí)的 SOAP響應(yīng)而不是 HTTP錯(cuò)誤，我們觀察下列輸出文件的內(nèi)容。這是符合上面要求的 SOAP響應(yīng)： soapenv:Envelope xmlns:soapenv= soapenv:Header/ soapenv:Body m:calculateAreaResponse xmlns:m= m:return12/m:return /m:calculateAreaResponse /soapenv:Body /soapenv:Envelope 為了使測(cè)試結(jié)果更加可視化，向計(jì)劃中添加 Spline Visualizer，它緊靠 著 Graph
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1