标签：
在编写一个网络服务的时候都比较关心这个服务能达到多少并发连接,而在这连接的基础上又能达到一个怎样的交互能力.编写服务已经是一件很花力气的事情,而还要去编写一个能够体现结果的测试工具就更加消耗工作时间.下面介绍一个测试工具只需要简单地设置一下就能对tcp/udp服务进行高并发和高吐吞的性能测试,并通过图形化的方式反映测试结果.
工具是采用用.NET编写,所以需要.NET FRAMEWORK才能运行.虽然.net在这方面的给人的感觉性能不怎么出色,但这个工作出色性能足够满足大部分服务端的压力测试.
? 
工具非常简单易用,只需要设置几项内容就可以对于个服务端进行压测.在这里比较注意的就是测试模式这里,工具主要提供两种测试模式分别是
应答模式:当连接接收服务端响应后马上进行下一次请求消息发送
间隔模式:连接根据设置的间隔时间来进行发送请求消息
在发起测试之前还需要给工作添加测试消息,明确工具向服务器发送那些消息内容
可以根据自己的需要编辑多发送的消息,每个连接都会轮遁把这些消息发送给服务端,消息的编码也可以根据自己需要设置.工具提供4种分别是:ascii,utf8,hex和base64.
当以上工作都准备好后就可以点击测试按钮进行测试,工具下方的几个曲线走势图会反映测试过程数据收集的结果.通过这些结果你就能了解到服务端响应的情况和整体吞吐浏览走势.
工具到底具备怎样的压力效能呢,下面通过两个测试用例反映工具具备的测试能力.
构建一个简单的TCP服务,然后在另一台机构建5000个连接的请求测试(测试电脑是一台笔记本),请求消息大小为1K;测试结果如下:
从结果来看5000个连接请求测试结果反映出整体交互是每秒6W个发送和6W个接收,而产生带宽上下行分别是60MB,那基本已经把测试环境1Gb的带宽跑完了.从系统的资源管理器来看的确是这样子.
这个测试主要把发送的消息设置成4K,由于网络环境所以只能把测试工具和服务端放在同一台PC上.而测试的连接数降到的2000个
测试结果反映socket的读写量分别是4W左右,而上下行的带宽分别170MB左右,算起来大概带宽达到3-4Gb之间.
组件也可以对HTTP进行测试,由于测试工具是基于长连接测试,所以请求描述必须用HTTP 1.1,并设置keep-alive;具体消息设置如下:
从以上两个测试用例的结果反映,工具具备着非常不错的压力测试效率.相信对于大部分TCP/UDP服务压力测试工作都能胜任.由于工作采用的随机端口分配,所以在创建连接的数量上会有一定的限制,后面会调整一下根据本机IP情况过行手动绑定,这样相信可以满足一些需大量连接服务测试.
标签：
原文地址：http://www.cnblogs.com/smark/p/4496660.html
