關于一個好的Load Generator

　　在做性能測試的時候，最基本也是必需的一個工具就是所謂的load generator，說白了就是用來產生測試流量的工具，或者是大的工具中的一個模塊。Load Generator是LoadRunner的叫法，因為它用得比較廣，所以這個名字也廣為人知了。

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

　　HTTP可能不是個很好的例子，因為HTTP load generator滿世界都是，要求不高的話找個free的很容易，誰叫web的performance最普遍呢。如果是其他協議，可能就沒有這么普通了，或者說能滿足實際項目要求的就更少了，對冷門的或者私有的協議就更慘一點。

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

　　最近在看公司里面一個用Ruby寫的automation的framework，于是順便study了下Ruby，然后就寫了個SMTP client。其實team倒是不缺這個，不過當是POC了。

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

　　區區三十行代碼就可以實現一個多線程的SMTP client，從15K.eml這個文件中讀取mail header和boby，然后發出去。

　　如果不嫌棄的話，理論上這個就可以用來作為SMTP performance測試的load generator，然后可以看你的MTA或者Mail server每秒可以處理多少封這種15KB size的純文本mail，聽起來有點意義。

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

　　測試環境很簡單，在本地起一個類似postfix smtp-sink的fake的MTA, 稱它fake是因為它收到mail之后全部在內存丟棄，所以沒有IO的壓力，相比真的mail server要快很多很多倍，而且從client的角度它是一個正常的MTA。之前試過這個fake的MTA在一個Thinkpad T60上可以把1Gbps 帶寬用滿，而且自己CPU usage還不是太高。說了這么多，意思就是說測試中Mail server不會是bottleneck， 所以可以看出client的極限。

　　HW: PC, Core 2 E6550 @2.33 GHz, 2GB RAM.

　　15K的sample是一次讀入內存，后面不會有大量的IO。

　　測試的結果是如果單線程發1000封的話，大概可以到 50 msg/s, 2個線程的話可以上到80左右，再增加就上不去了，可能因為就兩個核。理論上應該可以更高，這里先放一邊。

　　算算其實也相當快了，80 msg/s = 288,000 msg/hour = 6,912,000 msg/day

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

　　當然你要說和pure C的client比，那還是要差不少，pure C的至少200+，不過寫起來就要復雜很多了，主要是socket和multi thread的處理。

　　大概是因為常做系統穩定性測試的原因，本能的我想看看這個工具在大壓力長時間運行的時候穩定性如何。還是10個thread，但是把循環次數加大。結果出問題了。

　　注：代碼注釋調整過，所以行號可能對不上。

　　連著試了好幾次，每次都是到幾千封的時候出錯，發往smtp-sink也試過，還是一樣。從stack看起來是在讀取網絡數據的時候buffer handle出問題。應該是流量大的時候有些東西沒有handle好。當然這一部分是可以繼續改進的，加一些error handling和flow control的東西。

　　不過在這里我想說的意思是一個可以并發的client并不等于一個Load generator

　　Multi-thread client != Load Generator

　　因為load generator其實隱含了一個意思就是它自身不至于因為大的流量出問題，因為它是用來衡量別人的性能，如果自己出問題測試結果就沒有意義了。而且一個實用的性能測試工具中，load generator做的事情除了產生流量外，還有一個很重要的工作就是記錄響應數據，比如concurrent connection，response time，error rate等等，因為這些數據只有它最清楚。

　　一個好的load generator真的是要求很高的，自身就應該是高性能的，穩定的，可以擴展的網絡應用程序。不是一個隨便就可以寫出的并發了流量的東西。大家在使用工具久了就會發現很多廣為使用的性能測試工具也會自己出問題，我就遇到過測試工具crash或者memory leak的問題，比如JMeter，SilkPerformer還有Avalanche等測試設備。當然只是很偶然的發生，那么這個工具還是可用的了，但是如果像我上面寫的這個這個脆弱的client，就難以擔重任了。

　　好了，就寫到這里吧。

　　Inspired by Kevin Y. during some coffee talk, and also thanks for his kindly help on Ruby!

　　by Ricky

　　Jan, 2010

原文轉自：http://www.anti-gravitydesign.com