性能测试执行

1. 性能测试准备

1.1 性能测试环境申请

当做完性能需求分析之后，就要申请性能测试环境。因为性能测试需要在物理机上运行，而物理机又是稀缺资源，所以我们每次做性能测试都需要提前申请。

1.2 环境清理

  在部署系统之前必须要做的一件事就是环境清理，最简单的就是统统删除然后重新搭建一个干净无污染的系统。如果是在旧系统上做更新，那至少也得把Log日志清理一下、其他可能的干扰进程该杀就杀掉、定时跑的任务、临时文件、初始化文件等等该清理的都清理。

1.3 环境搭建及数据准备

环境搭建理想的情况是使用我们的环境搭建平台，或者一键式环境搭建脚本。当然，如果都没有的话，我们就得按照我们的上线步骤流程来一步步搭建了。

1.4 压力工具选择

  当我们做了性能需求分析、制定了测试方案，这时候需要选取一款合适的性能测试工具，并通过这个工具快速高效的完成测试任务。通常我们用的压力工具，如：ab、JMeter、LoadRunner等工具，这些在网上都有各种的使用方法，这里就不再一一介绍了。

  我们需要了解不同的压力工具的特点。

比如apache的ab，它是采用了Linux 2.6内核之后引入的epoll模型，能够制造非常高的压力，尤其是在高并发的环境下最能体现出它的优势。如果我们要压某个耗时稍长的请求，比如某个css静态文件，ab是非常合适的。Ab的缺点是不够灵活。

 JMeter采用的是多线程模型，扩展性很强，不过制造压力没有那么高。它很适合用来压一些Tomcat服务，或者一些后端接口。JMeter的缺点是压力值不能精确控制，难以适应高并发的情况。

LoadRunner更像是一个模拟器，它比较适用于前端构造较复杂场景的情况，比如模拟100个用户登录的场景，LoadRunner对非技术人员提供了很好的支持。LoadRunner不适用后端接口。

下图为JMeter和LoadRunner对比表：

描述	JMeter	LoadRunner
架构原理	通过中间代理，监控和收集并发客户端的指令，把他们生成脚本，再发送的应用服务器，再监控应用服务器反馈的过程	同JMeter
安装	简单，解压即可	LoadRunner安装包有1G多，安装通常要一个多小时，要是装过较旧的盗版还不能再装新版
支持的协议	支持多种协议：HTTP、HTTPS、SOAP、FTP、Database via JDBC、LDAP、JMS、SMTP、POP3、IMAP、MongoDB (NoSQL)、Native commands or shell scripts、TCP等	同JMeter
脚本录制	提供了一个利用本地ProxyServer（代理服务器）来录制生成测试脚本的功能，也支持badboy录制再生成JMeter脚本	自带录制功能强大，可直接录制回放
并发模型	通过增加线程组的数目，或者是设置循环次数来增加并发用户	支持多种并发模型，通过在场景中选择要设置什么样的场景，然后选择虚拟用户数
分布式测试	支持，可设置多台代理，通过远程控制实现多台机器并发压力	同JMeter
资源监控	通过JMeterPlugins插件和ServerAgent实现	自带资源监控功能
报告分析	通过与Ant集成，生成HTML报告	自身支持生成HTML、Word报告
虚拟IP	不支持	支持
网速模拟	不支持	支持
扩展性	开源，可根据需求修改源码	通过扩展函数库实现
学习成本	主要是自学官网上的资料，	网上资料和相关培训很多，购买正版的话，还有技术支持

1.5 资源监控工具部署

  Linux系统资源、JVM等监控工具非常多，目前入选的有nmon（Linux系统资源）、jstat、lsof、jmap、jstrace等工具，我们的脚本将这些监控工具综合起来一起。对数据库也需要监控，错误的SQL、慢查询SQL等都是很重要的线索，具体监控形式还需要与DBA协商。

2. 性能测试执行

2.1 无人值守执行性能测试

无人值守是最理想化的目标，目前我们也朝着这个方向努力。

无人值守不是说没有人力介入，而是把人为的分析和创造性的设计融入到性能测试设计里，至于执行过程只是机器服从指令的运行而已。

通常我们的线下测试环境在白天比较繁忙，各种服务交叉影响，出现性能问题及定位难度较大。

所以建议性能测试最好在晚上进行，相对较安静的条件有利于测试结果的稳定性。

2.2 动态调优

性能测试的吸引力之一就在于它的不可预知性。可能你以前也遇到过，一个服务接口，压力怎么也上不去。费了半天劲，最后才发现是压力工具的问题。

当我们在做压力测试的时候遇到跟预期不符的情况很正常，这个时候需要冷静的分析。问题的种类五花八门，这里无法一一罗列，但万变不离其宗，只要能打破沙锅问到底就没有解决不了的问题。

动态调优的过程其实也是对系统逐渐深入的过程，是后面性能优化的铺垫。

2.3 边执行边思考

性能测试是一个涉及知识面极广的工作，要成为一个性能测试专家需要不断积累，不停的思考。有些与性能相关的内容也许不会在性能测试报告中体现，但如果我们那么做了，我们会对系统的性能更有信心。

• 用户视角：

ü  还要让我等多久？——响应时间

ü  为什么总是失败？——稳定性

• 管理员视角：

ü  服务器资源使用合理吗？——资源利用率

ü  数据库使用合理吗？——资源利用率

ü  系统能否实现扩展？——可扩展性

ü  最多支撑多少用户访问？——系统容量

ü  最大业务处理量？——系统容量

ü  系统有哪些潜在的瓶颈？——可扩展性

ü  更换哪些设备，添加哪些机器可以提高系统性能？——可扩展性

ü  7 X 24 小时连续不间断业务访问？——稳定性

• 开发视角：

ü  架构设计是否合理？——架构设计

ü  数据库设计是否合理？——数据库设计

ü  代码是否存在性能问题？——代码

ü  是否有不合理的内存使用？——代码

ü  是否有不合理的线程同步操作？——代码

ü  是否有不合理的资源竞争？——代码

ü  代码算法是否还能有进一步提升？——代码

相信站在不同的角度思考，会有更深的理解。