1. 背景

　　项目已经进行了一段时间，系统业务流程、架构基本稳定，核心业务已经可以运作了，功能测试已经比较充分了，但系统的运维配套还没跟上。在这种情况下，进行了第一次性能测试。我觉得没必要对压力测试、负载测试等概念做细分了。

2. 准备工作

　　测试之前，必须给个规划：

（1）测试目的，第一次性能测试，目标不应该太高，了解系统性能概况，发现和解决大数据高并发下的代码级别的Bug

（2）数据模型，估算实际环境的数据量，并发数，制定一个大概的目标数据

（3）测试场景，不用多说，以主业务为测试场景，测之前至少把业务流程熟悉下

（4）环境配置，测试环境不比生产环境，可能缺各种硬件资源，需尽量减少环境对测试结果有效性的影响

（5）测试工具准备，压力工具，如LoadRunner，这个要早点定下了；监控工具，如JProfiler，这个倒可以后期调整

（6）测试用例准备，我们有功能测试的底子在，改吧改吧就出来了

3. 性能调优的优先级划分

　　性能测试是一个找瓶颈，调优，再找瓶颈，再调优，周而复始的过程，这不用多说了。我们对系统监控、调优的方向做了优先级的排序，修改代价小见效快的优先级高，这还是比较适合对系统性能不清楚的情况的：

• • 优先级0：消除一定并发下的程序Bug，保证业务成功率100%。这个只是后续测试的基础。
  • 优先级1：软硬件资源配置优化。例如，线程池就开了100，无论如何也达不到200的并发。这个调优效果最明显，不用修改代码，不用调整业务流程和架构。常见的有内存配额、线程池、数据库连接池、文件句柄数等，与使用的具体环境有关。
  • 优先级2：函数内的代码实现调优。代码功能上没问题，但执行效率不高，或者是资源使用不当导致了竞争，或者是单条SQL语句的优化，修改比较快，调优效果也会很不错。
  • 优先级3：函数内的代码结构调优。在不影响接口的前提下，算是对处理流程的微调。
  • 优先级4：业务流程或架构调整。这代价已经比较大了，牵扯到更多人的因素了，可能要找架构师、不同模块的开发人员，还可能资料也有修改。如果涉及到系统扩展，那更麻烦。

4. 性能测试的执行

　　我们没有成熟的运维系统，性能监控还是有点吃力的。那就要反复测，不停测，不断监控，得到想到的数据，分析问题所在。有时候系统明明很慢，但从监控数据中又分析不出原因，那就要增加监控项，不行的话就换更强的监控工具，总之要找到性能的瓶颈。对于如何监控，那就一言难尽了，主要的监控项有响应时间、吞吐率，系统资源如CPU、内存、进程或线程状态、IO、虚拟内存，java还需特别关注垃圾回收，数据库如SQL语句、锁、事件时间、缓存命中率。

　　不得不说的是，性能测试涉及到的环节太多，需要怀疑一切。举个例子，曾经出现严重负载不均的情况，换了负载均衡算法、会话保持策略都没用，后来发现是一个误操作，把负载均衡的参数配错了。再举一个例子，高并发下数据库崩溃了，又半天没找到原因，代码review了不知多少遍，后来发现是因为数据库磁盘满了。