.Net站点架构时间（八）測试
在定义好各部分的測试策略后。详细的工具使用选择倒不是主要问题。
1、不同省份、不同运营商CDN节点性能
此部分能够採用典型压力測试的方案。
2、核心机房BGP网络带宽
此部分重点在于測试各运营商BGP网络可靠性、实际速率等。一般採用smokeping、IxChariot等工具。
3、各类硬件设备性能
此部分一般採用专业的网络设备測试工具。
4、各类server（Webserver、应用server、缓存server等）并发性能、分布式处理能力
此部分能够採用压力測试方案及工具。
6、业务系统性能
此部分能够採用业务系统压力測试方案。
7、数据库处理性能
大部分互联网公司都对数据库作了定制改造以满足业务须要，此部分測试须要结合业务系统进行測试。以获取核心业务场景下数据库的TPS/QPS，尤其是測试定制改造的地方。
8、支付渠道接口及分流測试
此部分相对而言可能是最大的瓶颈所在，也是互联网公司们无法全然掌控的地方，仅仅能协调银行总部改造支撑。
另外还涉及备份方案、容灾方案、业务降级方案的測试。
这里指的业务降级方案。是基于“有损服务、柔性可用”的策略。为保证核心服务可用的前提下，对部分服务的质量降级处理。
作者：梁川
链接：http://www.zhihu.com/question/22216942/answer/78753248
来源：知乎
著作权归作者全部。商业转载请联系作者获得授权，非商业转载请注明出处。
工具是採用用.NET编写,所以须要.NET FRAMEWORK才干执行.尽管.net在这方面的给人的感觉性能不怎么出色,但这个工作出色性能足够满足大部分服务端的压力測试.
工具主界面
工具很easy易用,仅仅须要设置几项内容就能够对于个服务端进行压測.在这里比較注意的就是測试模式这里,工具主要提供两种測试模式各自是
应答模式:当连接接收服务端响应后立即进行下一次请求消息发送
间隔模式:连接依据设置的间隔时间来进行发送请求消息
消息编辑
在发起測试之前还须要给工作加入測试消息,明白工具向server发送那些消息内容
能够依据自己的须要编辑多发送的消息,每一个连接都会轮遁把这些消息发送给服务端,消息的编码也能够依据自己须要设置.工具提供4种各自是:ascii,utf8,hex和base64.
当以上工作都准备好后就能够点击測试button进行測试,工具下方的几个曲线走势图会反映測试过程数据收集的结果.通过这些结果你就能了解到服务端响应的情况和总体吞吐浏览走势.
工具究竟具备如何的压力效能呢,以下通过两个測试用例反映工具具备的測试能力.
測试用例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服务压力測试工作都能胜任.因为工作採用的随机port分配,所以在创建连接的数量上会有一定的限制,后面会调整一下依据本机IP情况过行手动绑定,这样相信能够满足一些需大量连接服务測试.
http://blog.liuts.com/post/234/