共计 1256 个字符，预计需要花费 4 分钟才能阅读完成。
本篇文章为大家展示了如何理解 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
上述内容就是如何理解 Storm 的性能测试报告，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注丸趣 TV 行业资讯频道。
