在项目初期,性能测试、调优的小结
2012-04-19 02:21
357 查看
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了不知多少遍,后来发现是因为数据库磁盘满了。
项目已经进行了一段时间,系统业务流程、架构基本稳定,核心业务已经可以运作了,功能测试已经比较充分了,但系统的运维配套还没跟上。在这种情况下,进行了第一次性能测试。我觉得没必要对压力测试、负载测试等概念做细分了。
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了不知多少遍,后来发现是因为数据库磁盘满了。
相关文章推荐
- 银行性能测试项目小结
- 性能调优项目测试与优化
- 项目压力测试 出分析报告 性能调优
- 一次真实项目性能测试与调优的总结
- 一次真实项目性能测试与调优的总结
- 一次真实项目性能测试与调优的总结
- JAVA性能测试与调优案例
- 使用JMeter对Tomcat进行压力测试与Tomcat性能调优
- j2ee性能调优之最小化资源压力测试法则
- 性能测试调优总结与分享
- 性能测试工具 nGrinder 项目剖析及二次开发
- 性能测试日志(apache+jboss调优)
- Java Web项目性能测试 - JMeter测试网站吞吐量、反应时间百分比、流量
- LoadRunner在性能测试工作中遇到的问题以及解决办法小结
- Spark性能调优1-测试记录
- 性能测试工具Loadrunner使用经验小结(原创更新版)
- 高并发,分布式,高可用,性能调优,系统架构,大型电商项目实战
- 性能测试之Apache性能调优课程
- Oracle sql 调优:使用虚拟索引在生产环境测试创建索引对数据库性能的影响
- 三种web性能压力测试工具http_load webbench ab小结