1. 调优的层次划分
应用系统调优分为四个层次（自下而上）：
（1）操作系统调优
（2）JVM调优
（3）WebLogic Server 调优
（4）应用程序调优
调优的顺序应该“自上而下”，首先应该“调优”应用：正确的架构，优秀的设计模式，重构代码。
然后在逐层依次“调优”，其中WebLogic Server 调优位于第三个层次，主要用来调优EJB 容器。
调优是一个循序渐进的过程：Run->Good->Fast。
2. 性能的度量指标
（1）响应时间（Response Time）： 比如，服务器交付一个Web页面的时间。
（2）吞吐量（Throughput）：比如，单位时间内（每秒）响应请求的数量。
（3）资源占用（Resource utilization）：比如，CPU的使用百分比。
（4）可靠性（Reliability）：使用固定的负载（如最佳并发用户数）进行长时间的压力测试，观察系统的响应时间、吞吐量以及资源占用率的变化。
（5）可伸缩性（Scalability ）：当系统的负载（用户数、数据）增加时，通过简单的手段（比如增加服务器，修改参数配置），就能够使系统容量线性增长。
（6）高可用性（High Availability）：有些系统要求7×24×365的连续稳定的服务，比如ATM，电子商务系统。
（7）可恢复性（Recoverability）：当发生意外后，系统可以恢复到正常的状态，并继续为用户提供服务——就像没有发生过意外一样。
注：（5）和（6）的常用解决方案是使用负载均衡（Load Balance）和集群（Cluster）技术。3. 建立测量基准（benchmarks）
（1）尽量模拟真实环境（硬件、软件、网络）：比如是否需要连接数据库，用户是否来自广域网，是否需要持久化数据。
（2）选择3到4个最关心的主要功能进行长时间（一周）的测试。
（3）修改代码或参数，反复测试，直到满足测量基准。注意，每次只修改一个参数，确定该参数对系统性能的影响。
4. 进行压力测试（Stress Testing）
压力测试主要用来测量系统的两个数据：
（1）最大并发用户数
（2）最大数据量
注意：压力测试必须保证所有请求都成功得到了响应。
4.1 辨析“最佳并发用户数”和“最大并发用户数”
详见参考文献2结论：对于一个系统来说，我们应该确保两条
1. 系统的最大并发用户数 >= 系统的峰值负载。2. 系统的最佳并发用户数 >= 系统的平均负载。所以，当我们通过长时间的压力测试（一周）来验证系统的可靠性/稳定性时，应该使用“最佳并发用户数”，而不是“最大并发用户数”，因为压力测试必须保证所有请求都成功得到了响应。
4.2 测试工具Grinder – http://grinder.sourceforge.net
JMeter – http://jakarta.apache.org/jmeter
LoadSim – http://java-source.net/open-source/web-testing-tools/loadsim
LoadRunner – http://www.mercury.com/us/products/loadrunner
RadView – http://www.radview.com
eLoad – http://www.empirix.com
5. 确认瓶颈的所在
5.1 CPU 瓶颈典型现象：CPU利用率始终接近100%。此时，增加工作线程也无济于事，因为CPU已经满负荷地在运行其它线程了。
说明：CPU利用率过高或过低都不好，峰值负载在85%-95%，普通负载在50%-75%均视为正常。
产生原因：
（1）垃圾回收参数设置不当
（2）内存参数设置不当，导致频繁使用Disk作为虚拟内存
（3）应用程序自身，存在死锁或死循环
分析手段：
（1）监测垃圾回收状况
（2）使用CPU侦测工具侦测应用程序
5.2 I/O 瓶颈
典型现象：CPU利用率尚未达到90%-100%，性能度量指标：TPS与负载状况（无论高低）无关。
比如：无论有多少个并发客户发出请求，每秒钟只有50个事务提交到数据库。
I/O 瓶颈可分为数据库瓶颈或网络瓶颈。
5.2.1 数据库瓶颈
产生原因：
（1）某些SQL语句非常耗时
（2）多个并发客户在等待数据库连接
（3）该机器还有别的应用，占用大量I/O
（4）应用程序自身，查询SQL语句没有优化
分析手段：
（1）可以使用Automatic Workload Repository (AWR) 来收集如下数据，帮助我们分析 Oracle DB：
Wait events used to identify performance problems
Time model statistics indicating the amount of DB time associated with a process
Active Session History (ASH) statistics
Some system and session statistics
Database object usage statistics
Resource intensive SQL statements
解决方案：
（1）为经常查询的条件字段增加索引
（2）增加数据库连接数
（3）让数据库独占一台速度较快的机器
（4）如果以上手段都不行，那么可以参考数据库手册进行调优。
5.2.2 网络瓶颈
产生原因：
（1）带宽已经饱和（注：50%的带宽被持续占用即可视为带宽饱和）
（2）应用程序自身，频繁操作I/O
解决方案：
（1）增加带宽
（2）提高默认发送的数据包大小MTU
（3）参考操作系统手册进行调优
5.3 内存瓶颈典型现象：报OutOfMemoryError，此时观察CPU，利用率并未达到饱和。
产生原因：
（1）机器或JVM分配内存过小
（2）垃圾回收参数设置不当
（3）应用程序自身，存在内存泄漏
解决方案：
（1）增加机器或JVM分配内存
（2）监测垃圾回收
（3）使用内存侦测工具侦测应用程序
参考文献：
1. 《WebLogic Server Performance and Tuning 》
2. 《理发店模型》 作者：陈雷 (Jackei)
3. 《理解性能 》 作者：陈雷 (Jackei)
应用系统调优分为四个层次（自下而上）：
（1）操作系统调优
（2）JVM调优
（3）WebLogic Server 调优
（4）应用程序调优
调优的顺序应该“自上而下”，首先应该“调优”应用：正确的架构，优秀的设计模式，重构代码。
然后在逐层依次“调优”，其中WebLogic Server 调优位于第三个层次，主要用来调优EJB 容器。
调优是一个循序渐进的过程：Run->Good->Fast。
2. 性能的度量指标
（1）响应时间（Response Time）： 比如，服务器交付一个Web页面的时间。
（2）吞吐量（Throughput）：比如，单位时间内（每秒）响应请求的数量。
（3）资源占用（Resource utilization）：比如，CPU的使用百分比。
（4）可靠性（Reliability）：使用固定的负载（如最佳并发用户数）进行长时间的压力测试，观察系统的响应时间、吞吐量以及资源占用率的变化。
（5）可伸缩性（Scalability ）：当系统的负载（用户数、数据）增加时，通过简单的手段（比如增加服务器，修改参数配置），就能够使系统容量线性增长。
（6）高可用性（High Availability）：有些系统要求7×24×365的连续稳定的服务，比如ATM，电子商务系统。
（7）可恢复性（Recoverability）：当发生意外后，系统可以恢复到正常的状态，并继续为用户提供服务——就像没有发生过意外一样。
注：（5）和（6）的常用解决方案是使用负载均衡（Load Balance）和集群（Cluster）技术。3. 建立测量基准（benchmarks）
（1）尽量模拟真实环境（硬件、软件、网络）：比如是否需要连接数据库，用户是否来自广域网，是否需要持久化数据。
（2）选择3到4个最关心的主要功能进行长时间（一周）的测试。
（3）修改代码或参数，反复测试，直到满足测量基准。注意，每次只修改一个参数，确定该参数对系统性能的影响。
4. 进行压力测试（Stress Testing）
压力测试主要用来测量系统的两个数据：
（1）最大并发用户数
（2）最大数据量
注意：压力测试必须保证所有请求都成功得到了响应。
4.1 辨析“最佳并发用户数”和“最大并发用户数”
详见参考文献2结论：对于一个系统来说，我们应该确保两条
1. 系统的最大并发用户数 >= 系统的峰值负载。2. 系统的最佳并发用户数 >= 系统的平均负载。所以，当我们通过长时间的压力测试（一周）来验证系统的可靠性/稳定性时，应该使用“最佳并发用户数”，而不是“最大并发用户数”，因为压力测试必须保证所有请求都成功得到了响应。
4.2 测试工具Grinder – http://grinder.sourceforge.net
JMeter – http://jakarta.apache.org/jmeter
LoadSim – http://java-source.net/open-source/web-testing-tools/loadsim
LoadRunner – http://www.mercury.com/us/products/loadrunner
RadView – http://www.radview.com
eLoad – http://www.empirix.com
5. 确认瓶颈的所在
5.1 CPU 瓶颈典型现象：CPU利用率始终接近100%。此时，增加工作线程也无济于事，因为CPU已经满负荷地在运行其它线程了。
说明：CPU利用率过高或过低都不好，峰值负载在85%-95%，普通负载在50%-75%均视为正常。
产生原因：
（1）垃圾回收参数设置不当
（2）内存参数设置不当，导致频繁使用Disk作为虚拟内存
（3）应用程序自身，存在死锁或死循环
分析手段：
（1）监测垃圾回收状况
（2）使用CPU侦测工具侦测应用程序
5.2 I/O 瓶颈
典型现象：CPU利用率尚未达到90%-100%，性能度量指标：TPS与负载状况（无论高低）无关。
比如：无论有多少个并发客户发出请求，每秒钟只有50个事务提交到数据库。
I/O 瓶颈可分为数据库瓶颈或网络瓶颈。
5.2.1 数据库瓶颈
产生原因：
（1）某些SQL语句非常耗时
（2）多个并发客户在等待数据库连接
（3）该机器还有别的应用，占用大量I/O
（4）应用程序自身，查询SQL语句没有优化
分析手段：
（1）可以使用Automatic Workload Repository (AWR) 来收集如下数据，帮助我们分析 Oracle DB：
Wait events used to identify performance problems
Time model statistics indicating the amount of DB time associated with a process
Active Session History (ASH) statistics
Some system and session statistics
Database object usage statistics
Resource intensive SQL statements
解决方案：
（1）为经常查询的条件字段增加索引
（2）增加数据库连接数
（3）让数据库独占一台速度较快的机器
（4）如果以上手段都不行，那么可以参考数据库手册进行调优。
5.2.2 网络瓶颈
产生原因：
（1）带宽已经饱和（注：50%的带宽被持续占用即可视为带宽饱和）
（2）应用程序自身，频繁操作I/O
解决方案：
（1）增加带宽
（2）提高默认发送的数据包大小MTU
（3）参考操作系统手册进行调优
5.3 内存瓶颈典型现象：报OutOfMemoryError，此时观察CPU，利用率并未达到饱和。
产生原因：
（1）机器或JVM分配内存过小
（2）垃圾回收参数设置不当
（3）应用程序自身，存在内存泄漏
解决方案：
（1）增加机器或JVM分配内存
（2）监测垃圾回收
（3）使用内存侦测工具侦测应用程序
参考文献：
1. 《WebLogic Server Performance and Tuning 》
2. 《理发店模型》 作者：陈雷 (Jackei)
3. 《理解性能 》 作者：陈雷 (Jackei)
没有评论:
发表评论