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

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

 

一般而言，整体测试策略是：先针对部分进行性能及压力测试，得到各部分的峰值处理性能；再模拟整体流程测试，此时倒不用按照峰值跑，重点测试整体业务流程及业务预期负荷。
在定义好各部分的测试策略后，具体的工具使用选择倒不是主要问题。

1、不同省份、不同运营商cdn节点性能
此部分可以采用典型压力测试的方案。

2、核心机房bgp网络带宽
此部分重点在于测试各运营商bgp网络可靠性、实际速率等，一般采用smokeping、ixchariot等工具。

3、各类硬件设备性能
此部分一般采用专业的网络设备测试工具。

4、各类服务器（web服务器、应用服务器、缓存服务器等）并发性能、分布式处理能力
此部分可以采用压力测试方案及工具。

6、业务系统性能
此部分可以采用业务系统压力测试方案。

7、处理性能
大部分互联网公司都对数据库作了定制改造以满足业务需要，此部分测试需要结合业务系统进行测试，以获取核心业务场景下数据库的tps/qps，尤其是测试定制改造的地方。

8、支付渠道接口及分流测试
此部分相对而言可能是最大的瓶颈所在，也是互联网公司们无法完全掌控的地方，只能协调银行总部改造支撑。

另外还涉及备份方案、容灾方案、业务降级方案的测试。
这里指的业务降级方案，是基于“有损服务、柔性可用”的策略，为保证核心服务可用的前提下，对部分服务的质量降级处理。

作者：梁川
链接：https://www.zhihu.com/question/22216942/answer/78753248
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

 

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

 

工具是采用用.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情况过行手动绑定,这样相信可以满足一些需大量连接服务测试.

https://blog.liuts.com/post/234/