2）测试方法
在Client启动0-100多个线程，不停的访问Topology，向其发送一个字符串（1K-1M）。Topology会原封不动的返回该字符串。
测试过程就不详细展开了。直接说测试结果。
3）测试结论
该测试中，处理速度主要受限于客户端带宽。也就是说由于数据量大，客户端发的速度慢，低于Storm中topology的处理速度。
因此该测试只能得出DRPC方式中单个请求在不同数据大小时，storm的延迟时间。
简而言之，StormDRPC方式中，最小延迟为50ms（数据小于1K），当数据量大时，256K数据，延迟为125ms，512K时延迟为208ms。
所以Storm数据量较大的时，处理的延迟还是比较大的。
当然以上仅是在特定环境中的测试，仅供参考。
改进方法
根据个人经验，针对以上Storm延迟可以由以下改进方法：
1）数据可以先压缩后再交给storm处理，在具体的bolt中对其进行解压缩。根据个人测试zlib压缩1M的数据，压缩率为80%，既可以将数据研所为原来的20%。从而可以减小数据量，提高效率。而zlib对1M数据进行压缩、解压缩所用时间在10ms以内。可以使情况选用。见[参考7]
2）storm本身采用字符型传输，对于二进制数据必须进行编码。可采用base64编码。参见[参考5]，base64对1M数据的编码，解码时间也分别小于10ms。
3）在DRPC测试中，数据从Clinet到DRPCServer，到DRPC SPOUT，到BOLT，到RETURN Result,在到DRPCSERVER，最后返回Client传输多次，可以考虑使用内存数据库如redis，Client直接将数据放入redis，将其在redis中的路径进行传输，在需要时，由bolt从redis中获取。参见[参考8]。将1M数据在redis中存取，耗时也分别在10-20ms。
4）对于外部处理程序，如C++，可以采用JNI的方式，对ShellBolt进行改进，而不是启动新的进程在通过Json编码，Pipe传输与之通讯，从而也可以提交效率。参见[参考4]。
