性能测试思维与误区
Posted 性能测试之道
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了性能测试思维与误区相关的知识，希望对你有一定的参考价值。
》》》推荐阅读《《《
1、
2、
3、
4、
一、关于性能优化的误区与反思
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资源得到释放。
五、系统资源分为硬瓶颈与软瓶颈
CPU、内存、I/O是硬瓶颈。CPU利用率太高，的确说明存在硬瓶颈。
应用开发中，认为造成瓶颈，例如同一时刻只能处理单笔交易、串行批处理、大量的锁存在等，则是软瓶颈。此时导致了CPU、I/O利用率降低，而系统的整体吞吐量下降。
》》》推荐阅读《《《
1、
2、
3、
4、
6、
7、
8、
9、
10、
11、
12、
13、
14、
15、
16、
17、
18、
19、
20、
22、
23、
24、
25、
26、
27、
28、
以上是关于性能测试思维与误区的主要内容，如果未能解决你的问题，请参考以下文章