Storm的性能测试报告

在一次面试的过程之中，有CTO详细的询问了 对于机器性能的测试，如下所示：

配置如下：

1                   Cpu     8核   ×2 台机器

2                   主频     2.26

3                    操作系统 redhat

4                    网络千M的以太网

5                   Storm的版本号：0.6.1

测试方法

Storm 是一个流处理系统，它以tuple为基本单位，每个tuple可以包含多个字段（field）。我们给tuple定义两个字段：

• Data： 存放原始的数据，这里是1000字节的数据，此测试中我们仅仅是直接的转发数据，所以唯一的处理开销就是1000字节的内存拷贝

• ltsInfo： 时间戳信息，每经过一个处理模块，我们就在此字段中追加上当时的时间戳，最后统计模块就可以根据这些时间信息计算出总延迟等。由于不同的机器时间戳并不同步，这给计算延迟带来了固有误差，解决的办法就是把数据发送模块和最后的统计模块放到一台物理机上。

关于在分布式集群上测试storm的一个说明：在storm上，我们很难给某个模块（component）指定其运行的物理机，storm总是自动的把任务平均分配给集群中的各个机器，因此在测试中我们将使用storm的工作方式来扩展，而非设计非典型的情景（给某个component指定特定的机器来运行，从而打破这种平均分配原则）。

也就是采取了淘测试的机制来处理

内存的使用

淘宝的测试结果为 2万条/秒左右。

在我本地机器上测试是超过了2.5万条，其中的区别可能是淘宝在测试的过程之中加入了一些时间TimeStamp。

到目前位置还没有新加机器来进行一些横向的扩展。没有对比新加入的机器对于系统集群的计算能力有多少增加。

具体的测试方式请参考

淘测试的连接：

http://blog.linezing.com/?p=1048&replytocom=828

在我们的实际测试之中，GC 将对于数据的处理造成比较大的速度的改变。Tuple的处理会积压是一个特别常见现象。

测试结论

经过上面的测试我们可以得出以下的结论：

• storm单条流水线的处理能力大约为20000 tupe/s, (每个tuple大小为1000字节)

• storm系统本省的处理延迟为毫秒级

• 在集群中横向扩展可以增加系统的处理能力，实测结果为1.6倍

• Storm中大量的使用了线程，即使单条处理流水线的系统，也有十几个线程在同时运行，所以几乎所有的16个CPU都在运行状态，load average 约为 3.5

• Jvm GC一般情况下对系统性能影响有限，但是内存紧张时，GC会成为系统性能的瓶颈

• 使用外部处理程序性能下降明显，所以在高性能要求下，尽量使用storm内建的处理模式

测试的工具是用的：nmon