品味性能之道<一>:性能测试思维与误区
《java performance》《品悟性能优化 oracle》《面向模式的软件架构-模式系统》读书笔记应用调优分享。
性能问题的解决,首先需要有理论和方法论的指导。否则东一耙,西一棒子,那就是二师兄耕地。既没有从总体上把握住性能问题,同时又浪费了大量宝贵的资源和时间。另外,缺乏方法论的指导,很多问题的解决也只会成为隔靴抓痒,无法从根本上解决问题。
一、关于性能优化的误区与反思
1、性能优化就是调参数
- 简单地认为性能优化就是调系统参数;
- 系统参数调整是性能优化的必要条件,但不是充分条件;
- 系统参数一定要调,还要合理地调,但调好了并不一定能解决所有问题;
2、性能优化主要是DBA和系统管理员的工作
- 数据库性能主要是系统问题,是系统管理员工作;
- 性能优化与软件开发人员关系不大,开发过程中,应用开发人员只关注业务功能的实现;
- 应用设计和开发对系统性能影响极大;
3、开发阶段无须考虑太多性能问题
- 应用性能主要在系统即将上线,或已经上线之后才进行考虑,开发阶性能问题未被内如考虑;
- 系统考虑的目标应该是综合的,在最初设计阶段就应该全面深入考虑、综合平衡,按照综合最优目标进行合理设计开发;
- 性能问题与软件工程的所有时间周期相关,尤其是设计和开发阶段对于性能影响最大;
4、优化SQL,就是教人写SQL
- 错误的认为,告诉我如何改一改SQL,就能执行得更快点;
- 优化SQL语句的性能,关键是了解SQL语句的原理和执行计划;
5、多表连接性能太差
- 错误的认为,多表连接性能太差,应该尽量减少多表连接操作,或者通过应用分步做;
- 多表连接是关系数据库的技术精髓之一,Oracle提供了丰富的表连接技术,关键是开发人员应该了解Oracle各种表连接技术的原理和适用场景;
6、CPU利用率越低越好
- 错误的认为,CPU利用率越低越好,利用率高就紧张;
- 交易系统中,CPU利用率越低越好。而在批处理系统里,充分适用资源,CPU利用率越高越好;
7、内存扩容解决性能问题
- 错误的认为,数据处理都在内存完成,没有磁盘I/O,应该不会再有性能问题;
- 尽量在内存完成数据处理,避免I/O操作,的确是性能优化的重要手段,但不应掩盖应用软件自身的问题;
- 所有数据处理都在内存完成,虽然没有磁盘I/O,但同样会导致CPU利用率的提高,并且速度也未必满足需求;
- 从源头降低不合理的数据访问量才是正确的优化思路,无论不合理的访问是在内存还是在磁盘上完成;
8、性能分析就是分析底层细节
- 错误的认为,性能问题出现时,一定要深入JVM与Oracle的内部参数、等待事件、Latch、缓存池、trace文件等底层细节;
- 从优化角度来讲,JVM的Young Gen、Old Gen、Perem Gen大小,Oracle的等待事件、Latch等指标,并不是问题的根源,而只是问题的表象;
- 在应用层进行合理的优化,这些指标会随之下降。既直接了当,又效果明显;
二、性能调优指导思想
- 优化工作开始得越早,其效益也越高。同时,付出的成本也最小;
- 投产后才发现的问题有可能是灾难性的;
- 再好的硬件解决不了应用软件设计和开发的问题;
- 千万别讲性能优化全部寄托于硬件和系统层面;
三、性能调优方法论
首先,要有站在总体高度的全局观;
其次,应该采取自底向上的策略,先仔细检查硬件、网络层面相对简单的问题,再深入到系统软件和应用软件相对复杂的领域。
四、性能调优试压过程
一个正常的系统,在不断加压的过程,应该经历下面五个阶段:
第一阶段:并发用户逐渐增加,系统的TPS(每秒处理事务笔数)逐步增大,直到达到最大值,这一阶段事务的响应时间不会有太大变化,会非常稳定;
第二阶段:并发用户继续增加,TPS基本维持在最大值不变,但响应时间将会逐步变长。
第三阶段:并发用户继续增加,TPS将会有少量下降(20%以内),但是决不能快速急剧下降,响应时间仍会逐步变长。本阶段可以拒绝服务,但是不能宕机。
第四阶段:并发用户逐步减小,系统处理能力开始得到恢复,TPS能够逐步恢复到之前的最大值,响应时间开始变短;
第五阶段:压力逐步降为零,TPS继续降低,响应时间继续变快,所有占用的CPU/内存/IO资源得到释放。
第二阶段:并发用户继续增加,TPS基本维持在最大值不变,但响应时间将会逐步变长。
第三阶段:并发用户继续增加,TPS将会有少量下降(20%以内),但是决不能快速急剧下降,响应时间仍会逐步变长。本阶段可以拒绝服务,但是不能宕机。
第四阶段:并发用户逐步减小,系统处理能力开始得到恢复,TPS能够逐步恢复到之前的最大值,响应时间开始变短;
第五阶段:压力逐步降为零,TPS继续降低,响应时间继续变快,所有占用的CPU/内存/IO资源得到释放。
五、系统资源分为硬瓶颈与软瓶颈
CPU、内存、I/O是硬瓶颈。CPU利用率太高,的确说明存在硬瓶颈。
应用开发中,认为造成瓶颈,例如同一时刻只能处理单笔交易、串行批处理、大量的锁存在等,则是软瓶颈。此时导致了CPU、I/O利用率降低,而系统的整体吞吐量下降。
系列博客:
品味性能之道<一>:性能测试思维与误区品味性能之道<二>:性能工程师可以具备的专业素养
品味性能之道<三>:方法论
品味性能之道<四>:管理重于技术
品味性能之道<五>:SQL分析工具
品味性能之道<六>:图形化SQL分析工具
品味性能之道<七>:索引基础
品味性能之道<八>:Loadrunner关联技巧与字符处理
品味性能之道<九>:利用Loadrunner编写socket性能测试脚本简述
品味性能之道<十>:Oracle Hint
品味性能之道<十一>:JAVA中switch和if性能比较
深入理解Loadrunner中的Browser Emulation
使用Loadrunner对IBM MQ进行性能测试
怎么做性能测试--响应时间
浮生潦草闲愁广,一听啤酒一口尽