Home | 简体中文 | 繁体中文 | 杂文 | 知乎专栏 | 51CTO学院 | CSDN程序员研修院 | Github | OSChina 博客 | 腾讯云社区 | 阿里云栖社区 | Facebook | Linkedin | Youtube | 打赏(Donations) | About
知乎专栏多维度架构

第 20 章 多维度架构之压力测试

目录

20.1. 压力测试中存在的问题
20.1.1. (What) 什么是压力测试
20.1.1.1. 压力测试存在哪些问题
20.1.2. (Why) 为什么做压力测试
20.1.3. (Where) 在哪里做压力测试
20.1.4. (When) 什么时间做压力测试
20.1.5. (Who) 压力测试过程参与人员
20.1.6. (How) 如何做压力测试
20.2. 协议测试
20.2.1. What 什么是协议测试
20.2.2. Why 为什么要做协议测试
20.2.3. where 在哪儿测试
20.2.4. when 什么时候测试
20.2.5. Who 谁来做,执行对象
20.2.6. How 怎样做测试
20.2.7. 如何学习协议测试
20.2.8. 总结
20.3. 打破软件自动化测试的格局
20.3.1. 自动化测试的误区
20.3.2. 分层与部署带来的问题
20.3.3. 压力测试存在的问题
20.3.3.1. 压力测试环境
20.3.3.2. 测试顺序
20.3.3.3. 瓶颈分析
20.3.3.4. 指导开发
20.3.4. 持续集成形同虚设
20.3.5. 测试的终极目标

20.1. 压力测试中存在的问题

20.1.1. (What) 什么是压力测试

软件压力测试是一种基本的质量保证行为,它是每个重要软件测试工作的一部分。软件压力测试的基本思路很简单: 不是在常规条件下运行手动或自动测试,而是在计算机数量较少或系统资源匮乏的条件下运行测试。 通常要进行软件压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽。

压力测试涵盖,性能测试,负载测试,并发测试等等,这些测试点常常交织耦合在一起。

20.1.1.1. 压力测试存在哪些问题

我归纳一下有几点:

  1. 操作系统默认安装,在未做任何优化的情况下实施压力测试

  2. 未考虑磁盘IO对软件的影响

  3. 未考虑网络带宽对软件的影响

  4. 网络软件测试,没有考虑到TCP特点

  5. 各种超时参数优化

  6. 测试客户端未优化

  7. 并发理解有误

  8. WEB服务器,数据库,等等服务器未优化

如果上面几项没有做优化,压力测试数据基本没有任何参考价值,任何一项没有优化,都会导致你的压力测试数据出现偏差。 下面我来逐条说明:

  1. 操作系统问题: 操作系统是大众化软件,出厂优化都是面向大众,不可能为某个领域做单独优化。所以我们第一步需要优化操作系统。 Linux 系统优化内核参数,Windows 系统优化注册表等等。

  2. 磁盘IO: 这是最容易出现瓶颈的地方,常常是CPU还没有达到极限,磁盘已经不堪重负。

  3. 网络IO: 与磁盘IO相同

  4. TCP连接: 几乎所有 B/S, C/S 软件都是采用多线程,或者多进程技术。这种技术有个特点,开发者将程序设计为线程可自动伸缩模式,开启进程后会启动少量线程,当连接不断提高后,线程数逐渐增加,随着线程运行结束后,线程逐渐减少。 这样的设计会更有效地利用硬件资源,在程序空闲时将硬件资源让给其他进程。少有软件设计为开启服务独占资源。 这样测试软件做压力测试,不能一次并发很多请求,而是要采用逐渐增加的方式,否则第一次测试会有一部分并发不能及时响应,导致测试数据偏差。另外也你可以多做几次压力请求(让多线程工作起来),从第三次开始记录测试数据,忽略前面两次的测试数据。

提示:另一个问题是TCP连接复用,这也是一个重要配置项。如果这项没有配置,我想测试出的数据也会有偏差

  1. 超时参数: 超时参数在压力测试中是非常重要的参数,例如从WEB到数据库连接超时是60秒,如果有一个SQL查询超过300秒,那么后面的请求会持续排队等待,当连接数达到数据库的最大连接时,接下来的所有请求都是失败的。 通常我们的WEB服务器超时不会超过30秒,有时我设置为10秒,一旦出现超时,宁可让该连接Timeout,不要让他影响整体服务。

  2. 客户端: 很多网络软件需要从客户端发出压力测试请求,所以客户端的优化也是必须的,否则客户端压力出不去,服务端压力进不来。

  3. 并发: 很多人认为并发,就是同一时间内的最大连接数,这是错误的。如果你写过多线程程序,就会发现多线程运行时有规律的。是顺序排队运行的,根本不是同时运行的。 所以并发是指,相对时间内能完成的连接总和,例如,每秒并发,每分钟并发等等,通常我们已秒为单位。 我们目前使用的操作系统叫分时操作系统,这种系统的特点就是可能实现多用户,多任务。操作系统将进程排队(优先级)轮询运行,只不过这个操作太快了,使你认为多个进程在同时运行。

  4. 服务器优化: 主要B/S软件压力测试,WEB,缓存,数据库等等服务器,都需要逐一优化到最佳状态

20.1.2. (Why) 为什么做压力测试

如果在软件设计阶段都将这些问题元素都考虑进去,同时开发阶段严格执行。那么开发出些软件几乎不用做这个劳人伤神的压力测试。

所以在软件设计阶段就要考虑,灵活性,扩展性,可靠性与性能,还要考虑高可用与负载均衡。

同时软件优化伴随开发,持续集成,持续测试,持续部署。

20.1.3. (Where) 在哪里做压力测试

有些软件需要封闭的环境测试,不能在共享资源的环境中做测试。所以你有必要做Vlan隔离,甚至独立的路由器与交换机在封闭网络中测试。

20.1.4. (When) 什么时间做压力测试

任何时间都可能做压力测试,为什么我将“时间”重点提出呢?目前受地球自转影响,经常闰秒,你不的不考虑这个问题。

20.1.5. (Who) 压力测试过程参与人员

  1. 运维部门

  2. 开发部门

  3. 测试部门

20.1.6. (How) 如何做压力测试

下面我们举一些例子,讲述压力测试方法,限于篇幅不可能面面俱到,我仅仅是给你提供思路。

测试前你需要一些监控工具,实时监控服务器的资源变化。

例如 Web 服务器压力测试,测试场景是 nginx :

    
    worker_processes  8;            处理器数
    worker_rlimit_nofile 65530;     允许最多打开文件数
    worker_connections  4096;       最大连接数数为
    keepalive_timeout  65;          开启复用连接
    gzip  on;                       压缩传输数据
    
			

怎么测试呢?你要获得最大化性能吗?还是相对性能?我们通常需要的是满足需求就好的相对性能,而不是最大化性能。为什么呢?因为要获得最大化性能是要做出很多配置牺牲的,例如关闭日志,禁止访问时间等等。

按照上面的配置你的测试用例应该是,每次并发4000 请求 8000~10000 次, 你不能并发8000 请求 4000 这样测试。很是很多人常常犯的错误,所以测试者需要连接系统的配置参数,不能盲目使用数字实验。

上面我说过线程的开启时随着请求,逐渐增加的,所以首次发起测试数据是不准确的,通过pstree命令可以看到线程数量。等第三次以后线程逐渐增加到4096个,并且之前开启的TCP可以复用,这时测试的结果比较有说服力。

延伸阅读《Netkiller Web 手札》《Netkiller Testing 手札》《Netkiller Linux 手札》