一、性能问题分析原则:
1. 把事实与推测分开，用实际证据证明推测
2. 没有足够的证据之前，不对程序进行优化
3. 优先验证简单的假设
4. 日志文件没有报错不代表真的没有错误
5. 从系统到应用，从外到内层层剥离，缩小范围
6. 缩小范围后，在分割小单元进行反复验证压测，直至确定某个单元引起的性能问题
二、应用数据库的三大类性能问题：
1. 过量的数据库调用
常见的性能瓶颈来自过量的数据库调用，引发的问题不一定是SQL查询的Execute()或Update()，而是应用程序和数据库的交互。例如常见问题是指定了过于精细的查询条件，然后使用ResultSet.Net()
解决办法：从数据库中大量取得所要求的的数据，避免应用程序反复回调数据库。
2. 数据库连接池问题
解决办法：仔细分析程序代码，是否没有close()连接？是否遗漏了finally块？或者尽管有close()但并没有成功？
A． 连接池太小
连接池过小会导致池满后，新的用户无法与系统连接，在日志中出现错误
解决办法:数据库连接池=线程数X每个线程需要连接数据库的平均数X1.1（1.1的含义是增加10%的峰值期负载），通常每个线程需要连接数据库的平均数是1，即当线程池数为120时，数据库连接池数是132.
设置最初池大小=最大池大小。
3．SQL语句及索引或锁定属性问题
解决办法：优化SQL语句及其索引或锁定属性
4. 死锁
所谓死锁<DeadLock>：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。
死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。
解决办法：
尽量避免并发的执行涉及到修改数据的语句。
要求每一个事务一次就将所有要使用到的数据全部加锁，否则就不允许执行。
预先规定一个加锁顺序，所有的事务都必须按照这个顺序对数据执行封锁。如不同的过程在事务内部对对象的更新执行顺序应尽量保证一致。
每个事务的执行时间不可太长，对程序段的事务可考虑将其分割为几个事务。在事务中不要求输入，应该在事务之前得到输入，然后快速执行事务。
使用尽可能低的隔离级别。
数据存储空间离散法。该方法是指采用各种手段，将逻辑上在一个表中的数据分散的若干离散的空间上去，以便改善对表的访问性能。主要通过将大表按行或者列分解为若干小表，或者按照不同的用户群两种方法实现。
编写应用程序，让进程持有锁的时间尽可能短，这样其它进程就不必花太长的时间等待锁被释放。
SQL语句中不要使用太复杂的关联多表的查询；使用“执行计划”对SQL语句进行分析，对于有全表扫描的SQL语句，建立相应的索引进行优化。
三、性能调优注意要点：
1. 在应用系统的设计开发过程中，应始终把性能放在考虑的范围内
2. 确定清晰明确的性能目标是关键
3. 必须确保优化后的程序运行正常
4. 系统的性能更大程序上取决于良好的设计，调优技巧只是一个辅助手段
5. 调优过程是迭代渐进的过程，每次调优的结果都要反馈到后续的代码开发中
6. 性能调优不能以牺牲代码的可读性和可维护性为代价
四、常见的系统性能瓶颈：硬件瓶颈、操作系统、服务/框架、代码
性能测试的注意要点：
1． 性能测试应尽可能早的进行
与功能测试相同，性能测试进行的越早越容易发现并修复问题，当系统集成后，想要从众多模块中分析定位模块瓶颈十分困难，如在初期进行的话，问题自然迎刃而解。
2. 性能测试需要团队支持
质量是做出来的，不是测出来的。性能也同样，并不是拥有一个性能测试部门就能解决的，发现并定位解决从而提升软件的性能，性能的优化需要开发和相关部门的通力合作
3. 性能测试需要独立的测试环境
性能测试的测试环境相对功能测试有着更为严格的要去，需要独立的网络和硬件环境，保证被测系统的独立可控
4. 测试前定义明确的测试目标
性能测试的执行成本较高，为了确保性能测试执行的有效性，在每一次性能测试前都需要明确本次性能测试的目标，并对这个目标进行监控和验证
5. 不要在服务器上进行性能测试
虽然服务器可用来作为负载生成和被负载的对象，但是如果在服务器上进行这样的操作，系统资源会被负载消耗，导致得出的性能测试数据脱离实际情况
6. 创建的负载应该是模拟用户最常见、最密集的操作
在进行性能测试时，应模拟用户最常使用的功能，来了解在这种情况下的系统的资源消耗情况及用户体验
7. 在真正的性能测试前尽可能多的进行预测试
在性能测试开始前，尽可能多的进行预测试，发现负载生成的结果及负载生成是否存在瓶颈，性能测试成本较高，通过多次预测试，可以降低最终测试的成本和更为接近最真实的结果
8. 使用同一用户进行长时间大量操作是否存在内存泄露或者类似的错误
通常这样做会发现系统的某些功能设置上的问题。例如：使用同一用户长期进行负载操作后，系统可能会出现线程崩溃。
五、性能测试原理：
1. 用户行为模拟（成本低）
不同用户使用不同的数据（Loadrunner通过“参数化”实现）
多用户并发操作（loadrunner通过“集合点”实现）
用户请求间的依赖关系（Loadrunner通过“关联”实现）
请求间的延时时间（Loadrunner通过“思考时间”实现）
2. 性能指标监控
请求响应时间监控（Loadrunner通过“事务”来实现）
服务器处理能力监控（Loadrunner通过“事务”计算吞吐量获得）
服务器资源利用率监控（Loadrunner提供全面简洁的计数器接口）
3. 性能调优
通过指标的监控发现系统存在的性能缺陷，利用分析工具定位并修复。
六、编写性能测试计划的前提：
1. 系统真实环境平台的架构及软/硬件标准
2. 需要进行性能测试的模块及应对案例
3. 脚本开发中可能需要解决的技术
4. 业务完成与否的判断标准
5. 相关信息的监控策略
6. 场景模型的定义
7. 对系统负载后的结果预估
**明确以上性能测试目标后，即可开始编写性能测试工作。
从软件架构 网络 硬件架构 参数配置 数据库 测试策略方法 业务模型建立 以及整体实施的全流程的每个环节都要熟悉*
网友评论