Tw itter storm 性能测试报告 测试目的 测试twitter storm 的运行性能以及数据处理的延迟。 系统配置 CPU 个数 16 CPU 主频 2.26GHz 内存 16G OS Linux 2.6.32-xxx.x86_64 网络 千兆以太网 Storm 版本号 0.6.1 测试方法 Storm 是一个流处理系统，它以tuple 为基本单位，每个 tuple 可以包含多个字段（field）。我们给 tuple 定义两个字段： Data： 存放原始的数据，这里是 1000 字节的数据，此测试中我们仅仅是直接的转发数据，所以唯一的处理开销就是 1000 字节的内存拷贝 tsInfo： 时间戳信息，每经过一个处理模块，我们就在此字段中追加上当时的时间戳，最后统计模块就可以根据这些时间信息计算出总延迟等。由于不同的机器时间戳并不同步，这给计算延迟带来了固有误差，解决的办法就是把数据发送模块和最后的统计模块放到一台物理机上。 关于在分布式集群上测试storm 的一个说明：在 storm上，我们很难给某个模块（component）指定其运行的物理机，storm 总是自动的把任务平均分配给集群中的各个机器，因此在测试中我们将使用 storm 的工作方式来扩展，而非设计非典型的情景（给某个 component 指定特定的机器来运行，从而打破这种平均分配原则）。 各测试以及结果 a) 在单个主机上，采用如下的方式构造拓扑 系统资源的利用率如下 CPU 利用率 内存使用情况 吞吐量：平均值为 25253 条/秒 0 50 100 13:32 13:32 13:33 13:33 13:33 13:34 13:34 13:34 13:35 13:35 13:35 13:35 13:36 13:36 13:36 13:37 13:37 13:37 13:38 13:38 13:38 13:38 13:39 13:39 13:39 CPU Total 2012/1/17 User% Sys% Wait% 0 2 4 6 8 10 12 13:32 13:32 13:33 13:33 13:34 13:34 13:34 13:35 13:35 13:35 13:36 13:36 13:36 13:37 13:37 13:37 13:38 13:38 13:38 13:39 13:39 13:39 千 Memory MB 2012/1/17 memfree Sender Processer Stats 测试 结果 数据处理的延时如下图所示，（单位 毫秒） 数据处理延迟越来越大的原因是，后端数据处理模块处理的速度较慢，所以数据发送端发送的数据产生了累积，并且累积量越来愈大，所以延迟的值就越来越大。较精确的测试处理延迟方案见（测试 e） b ) 由上面的测试可知，processer 模块的处理速度跟不上 sender 的发送速度，导致数据累积在发送端，本测试用例并行扩展 ...
