.Net站点架构设计（八）測试

.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

来源：知乎

著作权归作者全部。商业转载请联系作者获得授权，非商业转载请注明出处。

‘在编写一个网络服务的时候都比較关心这个服务能达到多少并发连接,而在这连接的基础上又能达到一个如何的交互能力.编写服务已经是一件非常花力气的事情,而还要去编写一个可以体现结果的測试工具就更加消耗工作时间.以下介绍一个測试工具仅仅须要简单地设置一下就能对tcp/udp服务进行高并发和高吐吞的性能測试,并通过图形化的方式反映測试结果.

工具是採用用.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/