.Net网站架构设计（八）测试
.Net网站架构时间（八）测试
在定义好各部分的测试策略后，具体的工具使用选择倒不是主要问题。
1、不同省份、不同运营商CDN节点性能
此部分可以采用典型压力测试的方案。
2、核心机房BGP网络带宽
此部分重点在于测试各运营商BGP网络可靠性、实际速率等，一般采用smokeping、IxChariot等工具。
3、各类硬件设备性能
此部分一般采用专业的网络设备测试工具。
4、各类服务器（Web服务器、应用服务器、缓存服务器等）并发性能、分布式处理能力
此部分可以采用压力测试方案及工具。
6、业务系统性能
此部分可以采用业务系统压力测试方案。
7、数据库处理性能
大部分互联网公司都对数据库作了定制改造以满足业务需要，此部分测试需要结合业务系统进行测试，以获取核心业务场景下数据库的TPS/QPS，尤其是测试定制改造的地方。
8、支付渠道接口及分流测试
此部分相对而言可能是最大的瓶颈所在，也是互联网公司们无法完全掌控的地方，只能协调银行总部改造支撑。
另外还涉及备份方案、容灾方案、业务降级方案的测试。
这里指的业务降级方案，是基于“有损服务、柔性可用”的策略，为保证核心服务可用的前提下，对部分服务的质量降级处理。
作者：梁川
链接：http://www.zhihu.com/question/22216942/answer/78753248
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
工具是采用用.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情况过行手动绑定,这样相信可以满足一些需大量连接服务测试.
http://blog.liuts.com/post/234/