测试的结果是如果单线程发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，难以担重任了。