關(guān)于一個(gè)好的Load Generator

第第頁關(guān)于一個(gè)好的LoadGenerator關(guān)于一個(gè)好的LoadGenerator

發(fā)表于：2023-04-12來源：Csdn：superqa點(diǎn)擊數(shù)：標(biāo)簽：LoadGenerat

在做性能測(cè)試的時(shí)候，最基本也是必需的一個(gè)工具就是所謂的loadgenerator，說白了就是用來產(chǎn)生測(cè)試流量的工具，或者是大的工具中的一個(gè)模塊。LoadGenerator是LoadRunner的叫法，因?yàn)樗玫帽容^廣，所以這個(gè)名字也廣為人知了。

在做性能測(cè)試的時(shí)候，最基本也是必需的一個(gè)工具就是所謂的loadgenerator，說白了就是用來產(chǎn)生（測(cè)試）流量的工具，或者是大的工具中的一個(gè)模塊。LoadGenerator是LoadRunner的叫法，因?yàn)樗玫帽容^廣，所以這個(gè)名字也廣為人知了。

更清楚一點(diǎn)，舉個(gè)例子，為了模擬大量的HTTP客戶端來向server發(fā)起請(qǐng)求，你可以請(qǐng)一群人，起幾十個(gè)IE,然后喊口令請(qǐng)大家一起點(diǎn)，但是基本上這樣不work(不要問我原因，不信可以試一下，我倒是真在某處見過有單位這么干的)。實(shí)際中大家可能會(huì)用LoadRunner/（JMeter）/WAS等工具來模擬很多的并發(fā)用戶，產(chǎn)生大的流量。這個(gè)時(shí)候，上面的工具就是loadgenerator了，當(dāng)然它可能也同時(shí)被用作controller或者resourcemonitor。

HTTP可能不是個(gè)很好的例子，因?yàn)镠TTPloadgenerator滿世界都是，要求不高的話找個(gè)free的很容易，誰叫（web）的performance最普遍呢。如果是其他協(xié)議，可能就沒有這么普通了，或者說能滿足實(shí)際項(xiàng)目要求的就更少了，對(duì)冷門的或者私有的協(xié)議就更慘一點(diǎn)。

既然沒有很好的現(xiàn)成的，另一個(gè)途徑就是自己寫一個(gè)，咱是QA，但也是programmer，寫代碼也是分內(nèi)之事哈。而且現(xiàn)在的很多高級(jí)語言開發(fā)起來快得讓你自己都覺得不好意思，似乎得來太容易。

最近在看公司里面一個(gè)用Ruby寫的automation的framework，于是順便study了下Ruby，然后就寫了個(gè)SMTPclient。其實(shí)team倒是不缺這個(gè)，不過當(dāng)是POC了。

(為了保留Eclipse的顏色，看起來舒服點(diǎn)，就用snapshot了，反正代碼少到不值得copy:))

區(qū)區(qū)三十行代碼就可以實(shí)現(xiàn)一個(gè)多線程的SMTPclient，從15K.eml這個(gè)文件中讀取mailheader和boby，然后發(fā)出去。

如果不嫌棄的話，理論上這個(gè)就可以用來作為SMTPperformance測(cè)試的loadgenerator，然后可以看你的MTA或者M(jìn)ailserver每秒可以處理多少封這種15KBsize的純文本mail，聽起來有點(diǎn)意義。

世界真美好，我一邊在感嘆Ruby的簡潔和快速。不過既然是loadgenerator，自然要去看看這個(gè)小generator的極限能力是怎樣，就是看它能跑多快。之前對(duì)Ruby的（性能）也不了解。

測(cè)試環(huán)境很簡單，在本地起一個(gè)類似postfixsmtp-sink的fake的MTA,稱它fake是因?yàn)樗盏絤ail之后全部在內(nèi)存丟棄，所以沒有IO的壓力，相比真的mailserver要快很多很多倍，而且從client的角度它是一個(gè)正常的MTA。之前試過這個(gè)fake的MTA在一個(gè)ThinkpadT60上可以把1Gbps帶寬用滿，而且自己CPUusage還不是太高。說了這么多，意思就是說測(cè)試中Mailserver不會(huì)是bottleneck，所以可以看出client的極限。

HW:PC,Core2E6550@2.33GHz,2GBRAM.

15K的sample是一次讀入內(nèi)存，后面不會(huì)有大量的IO。

測(cè)試的結(jié)果是如果單線程發(fā)1000封的話，大概可以到50msg/s,2個(gè)線程的話可以上到80左右，再增加就上不去了，可能因?yàn)榫蛢蓚€(gè)核。理論上應(yīng)該可以更高，這里先放一邊。

算算其實(shí)也相當(dāng)快了，80msg/s=288,000msg/hour=6,912,000msg/day

全世界每天收到這么多mail的公司應(yīng)該不是很多了。

當(dāng)然你要說和pureC的client比，那還是要差不少，pureC的至少200+，不過寫起來就要復(fù)雜很多了，主要是socket和multithread的處理。

大概是因?yàn)槌Ｗ鱿到y(tǒng)穩(wěn)定性測(cè)試的原因，本能的我想看看這個(gè)工具在大壓力長時(shí)間運(yùn)行的時(shí)候穩(wěn)定性如何。還是10個(gè)thread，但是把循環(huán)次數(shù)加大。結(jié)果出問題了。

注：代碼解釋調(diào)整過，所以行號(hào)可能對(duì)不上。

連著試了好幾次，每次都是到幾千封的時(shí)候出錯(cuò)，發(fā)往smtp-sink也試過，還是一樣。從stack看起來是在讀取網(wǎng)絡(luò)數(shù)據(jù)的時(shí)候bufferhandle出問題。應(yīng)該是流量大的時(shí)候有些東西沒有handle好。當(dāng)然這一部分是可以繼續(xù)改進(jìn)的，加一些errorhandling和flowcontrol的東西。

不過在這里我想說的意思是一個(gè)可以并發(fā)的client并不等于一個(gè)Loadgenerator

Multi-threadclient!=LoadGenerator

因?yàn)閘oadgenerator其實(shí)隱含了一個(gè)意思就是它自身不至于因?yàn)榇蟮牧髁砍鰡栴}，因?yàn)樗怯脕砗饬縿e人的性能，如果自己出問題測(cè)試結(jié)果就沒有意義了。而且一個(gè)實(shí)用的性能測(cè)試工具中，loadgenerator做的事情除了產(chǎn)生流量外，還有一個(gè)很重要的工作就是記錄響應(yīng)數(shù)據(jù)，比如concurrentconnection，responsetime，errorrate等等，因?yàn)檫@些數(shù)據(jù)只有它最清楚。

一個(gè)好的loadgenerator真的是要求很高的，自身就應(yīng)該是高性能的，穩(wěn)定的，可以擴(kuò)展的網(wǎng)絡(luò)應(yīng)用程序。不是一個(gè)隨便就可以寫出的并發(fā)了流量的東西。大家在使用工具久了就會(huì)發(fā)現(xiàn)很多廣為使用的（性能測(cè)試）工具也會(huì)自己出問題，我就遇到過（測(cè)試工具）crash或者memoryleak的問題，比如JMeter，SilkPerformer還有Avalanche等測(cè)試設(shè)備。當(dāng)然只是很偶然的發(fā)生，那么這個(gè)工具還是可用的了，但是如果像我上面寫的這個(gè)這個(gè)脆弱的client，就難以擔(dān)重任了。

好了，就