.Net网站架构设计（八）测试

标签：

.Net网站架构时间（八）测试

        工具是采用用.NET编写,所以需要.NET FRAMEWORK才能运行.虽然.net在这方面的给人的感觉性能不怎么出色,但这个工作出色性能足够满足大部分服务端的压力测试.

工具主界面

?        

        工具非常简单易用,只需要设置几项内容就可以对于个服务端进行压测.在这里比较注意的就是测试模式这里,工具主要提供两种测试模式分别是

        应答模式:当连接接收服务端响应后马上进行下一次请求消息发送

        间隔模式:连接根据设置的间隔时间来进行发送请求消息

消息编辑

        在发起测试之前还需要给工作添加测试消息,明确工具向服务器发送那些消息内容

        可以根据自己的需要编辑多发送的消息,每个连接都会轮遁把这些消息发送给服务端,消息的编码也可以根据自己需要设置.工具提供4种分别是:ascii,utf8,hex和base64.

        当以上工作都准备好后就可以点击测试按钮进行测试,工具下方的几个曲线走势图会反映测试过程数据收集的结果.通过这些结果你就能了解到服务端响应的情况和整体吞吐浏览走势.

        工具到底具备怎样的压力效能呢,下面通过两个测试用例反映工具具备的测试能力.

测试用例1

        构建一个简单的TCP服务,然后在另一台机构建5000个连接的请求测试(测试电脑是一台笔记本),请求消息大小为1K;测试结果如下:

        从结果来看5000个连接请求测试结果反映出整体交互是每秒6W个发送和6W个接收,而产生带宽上下行分别是60MB,那基本已经把测试环境1Gb的带宽跑完了.从系统的资源管理器来看的确是这样子.

测试用例2 

        这个测试主要把发送的消息设置成4K,由于网络环境所以只能把测试工具和服务端放在同一台PC上.而测试的连接数降到的2000个

        测试结果反映socket的读写量分别是4W左右,而上下行的带宽分别170MB左右,算起来大概带宽达到3-4Gb之间.

HTTP测试

        组件也可以对HTTP进行测试,由于测试工具是基于长连接测试,所以请求描述必须用HTTP 1.1,并设置keep-alive;具体消息设置如下:

总结    

        从以上两个测试用例的结果反映,工具具备着非常不错的压力测试效率.相信对于大部分TCP/UDP服务压力测试工作都能胜任.由于工作采用的随机端口分配,所以在创建连接的数量上会有一定的限制,后面会调整一下根据本机IP情况过行手动绑定,这样相信可以满足一些需大量连接服务测试.

.Net网站架构设计（八）测试

标签：

原文地址：http://blog.csdn.net/liming850628/article/details/50723421