性能测试进阶4-分析篇
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
①
主要参数 缓存命中率
属性
描述
cacheMaxSize cacheTTL
cachingAllowed
Maximum size of the static resource cache in kilobytes. If not specified, the default value is 10240 (10 megabytes). Amount of time in milliseconds between cache entries revalidation. If not specified, the default value is 5000 (5 seconds). If the value of this flag is true, the cache for static resources will be used. If not specified, the default value of the flag is true.
从浏览器到数据库间的任何一个点都可能是应用程序错误或者是性能下降 的原因
性能问题的根源 分析需要从最基本 的性能报告一直分 析到每个组件的性 能数据
End-user experience Transaction Response Times
System-level performance Network and Server Response Times
①
②
Tomcat默认的缓存过期时间为5秒钟，此时间可 能过短，造成缓存失效。并发量较大情况下，静 态资源的缓存可以被充分利用。并发量较小情况 下，静态资源的缓存不能充分利用，造成效率低 下。 调整cacheTTL值为30分钟，进行试验。问题解 决。
优化前：
优化后：
性能问题：
在某系统的测试过程中，发现某张报表的查询时间超过80s， 访问很慢。
① ②
① ② ③
根据问题特点，初步怀疑是配置出了问题，首先怀疑是 apache与tomcat之间的问题。 检查tomcat的性能状态与工作日志。 Tomcat的busy线程数无法超过20。即同时处理的请求 数不超过20。 apache端日志会出现503错误，mod jk日志中会出现 “can't find free endpoint”错误。 打开mod_jk配置，发现cache size的值设为20。 查阅此参数的说明，worker.properties文件中的 worker.worker1.cachesize=xx和 worker.worker1.cache_timeout=xx两个选项在apache 1.2.16之后的版本已经废弃，但如果使用将仍然生效。当大 用户量时，apache的mod jk维持的连接数不会超过 cachesize值，否则将抛出错误，反映在apache端，为503 错误。
Query cache hit rate Query cache size Query cache limit Replication status Times behind master Queries inserts/ deleted / updated/ selected
观察进程内存利用情况时， 下面两项指标非常重要：
Operating System memory constraints Permanent memory anomalies
◦ Process memory utilization
掌握数据库主要性能指 标
◦ Connection statistics
使用过滤器来过滤特定的事务状态、事务名称、 group、Vuser等 可以使用全局过滤器也可以针对某张图使用过滤器 可以对过滤器使用条件或者，对数据进行过滤
Web服务器较慢一般 有如下原因：
◦ 负载过高 ◦ 配置不当 ◦ 其他问题
测试期间对web服务 器进行监控可以帮助 排查性能问题
性能测试结果
50用户在线访问
80用户在线访问
用户量越大，效率越高。即并发量越大，效率越 高。 ② 响应时间的差别主要体现在js的获取时间上 进一步分析， ① Js是静态资源，需要考虑tomcat对静态资源处理 的机制。 ② 根据访问特点（1），极有可能和缓存有关。 下一步方向， ① 查看tomcat的缓存机制
JVM参数设置太小，为512M，调整为1.6G后，问题解决。
性能监控Top 10 性能分析基础知识
J2EE架构性能监控Top 10
掌握应用程序端统计指标
◦ 响应时间
平均、最大、最小、90%、标准差
◦ 并发数 ◦ Hits per second ◦ 在线用户 ◦ 吞吐量 ◦ 常见错误
◦ Connection pools
◦ Caches
Hit count Miss count
Java虚拟机性能度量
◦ Heap performance
Heap utilization Heap growth pattern Garbage collection behavior
周保玉
Loadrunner结果分析 深入分析性能数据 案例分析
Explain the value of results analysis Diagnose errors with LoadRunner Interpret LoadRunner graphs to derive meaningful results by drilling down to root cause problems
Time to First Buffer is the period between a browser request and the first reply. Provides high level Server vs. Network determination
识别消耗时间最多 的页面，找出时间 都花费在哪些功能 上 可用隔离分析DNS 问题、SSL问题、连 接问题
Open connections Aborted connections Threads used Threads in cache
◦ Key efficiency
Key hit rate Key buffer used Key buffer size
◦ Query statistics ◦ Query cache hit rate
Component metrics
例子:
Our load testing goal is to be able to support 100 users with < 5 second transaction response time across all transactions Any issues that affect this should be identified and resolved
从负载增长情况和服务器的资源情况，可以进一步得到结论： 正是应用服务器的问题，导致了系统不能支持更大的负载。
检查错误日志/访问日 志
wenku.baidu.com
检查垃圾回收
可以发现堆内 存的使用持续走高， 达到最大值，造成 jvm内存短缺 。进 一步造成处理能力 下降，最终的表现 是连接堆积过多， 响应时间迅速变大。
背景 查看系统是否支持600人在线，各事务的响应时间在 12s以内 环境部署： 2台web，一台认证服务器，一台应用服务器 (tomcat) 6台mysql数据库服务器（一主5从）
在线人数达到550人时，响应时间突然变大
查看服务器资源，寻找趋势异常的服务器。CPU LOADAVERAGE 图与CPU 使用率图。Loadrunner的资源监控图线告诉我们，在响应时间异常的点，应 用服务器出现了性能问题。CPU average突然上升到42，CPU使用率也急剧 上升，达到60%以上，正常状态下为9%。
正常负载范围内， server的CPU 使 用率一般不应高 于70%. 运行期间，可用 的物理内存不应 太低
随着压力的增长，如果某个指标的曲线开始变得平坦， 往往意味着极限或者瓶颈已经出现。
在不断增长的负载下，如果连接数曲线开始变得平坦，往往意味web server端的问题 在不断增长的负载下，如果吞吐量图线开始变得平坦，往往意味着网 络带宽达到极限
排查过程：
• 查看主机资源 – 正常 • 查看数据库慢查询日志 – 找到慢sql
掌握App server性能度量主要参数
◦ Thread pools
Thread pool utilization Queue depth Request throughput Connection pool utilization Execute threads awaiting for a connection
单位时间内的访问数
单位时间内发送的请求数
掌握操作系统性能指标
◦ CPU
User time, sys time, io wait, idle Load average
◦ DISK IO ◦ NETWORK
磁盘读写速率、队列情况
网络读写速率
◦ MEMORY
Free, buffer, cache, swap
◦ Thread details
◦ Table lock statistics
Immediate locks Locks wait
◦ Replication details
连接池案例 Session案例 缺少索引案例 Tomcat缓存案例 MCPACK内存泄露
性能问题 在压力测试过程中，并发数上不去，web服务器、 应用服务器和数据库服务器资源都处于较低使用状 态。
Details transaction response throughout the test Identifies problematic transactions Identifies problematic points in the test
Details transaction response time as a function of load Identifies under what load conditions transaction times begin to degrade
性能测试期间能够收集的性能数据数量是惊人的。 因此，如果没有足够的技巧来处理这些数据，诊 断性能问题是不可能的。 LoadRunner Analysis的能力:
• 对数据进行过滤，隐藏不想看到的数据，突出重点关 注的数据 • 通过合并、自动关联等重新组织特定的数据，突出数 据间的联系 • Drill-Down capability
Details transaction response time as a service level Identifies percentage of transactions complete over time
Details transaction response time as a distribution count Identifies number of transactions complete over time
常用命令
◦ Top, vmstat, iostat, mpstat
◦ Swap
Used , free Si, so
◦ System
In, cs
Apache的性能度量
◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ Total Accesses 总的访问量 Total KBs 总的吞吐量 CPU Load CPU负载百分数 Uptime 启动以来的时间 Requests Per Second 每秒请求数 Bytes Per Second 每秒字节数 Bytes Per Req 每个请求的byte数 Busy Workers 处于busy状态的线程数 Idle Workers 处于idle状态的线程数
主要参数 缓存命中率
属性
描述
cacheMaxSize cacheTTL
cachingAllowed
Maximum size of the static resource cache in kilobytes. If not specified, the default value is 10240 (10 megabytes). Amount of time in milliseconds between cache entries revalidation. If not specified, the default value is 5000 (5 seconds). If the value of this flag is true, the cache for static resources will be used. If not specified, the default value of the flag is true.
从浏览器到数据库间的任何一个点都可能是应用程序错误或者是性能下降 的原因
性能问题的根源 分析需要从最基本 的性能报告一直分 析到每个组件的性 能数据
End-user experience Transaction Response Times
System-level performance Network and Server Response Times
①
②
Tomcat默认的缓存过期时间为5秒钟，此时间可 能过短，造成缓存失效。并发量较大情况下，静 态资源的缓存可以被充分利用。并发量较小情况 下，静态资源的缓存不能充分利用，造成效率低 下。 调整cacheTTL值为30分钟，进行试验。问题解 决。
优化前：
优化后：
性能问题：
在某系统的测试过程中，发现某张报表的查询时间超过80s， 访问很慢。
① ②
① ② ③
根据问题特点，初步怀疑是配置出了问题，首先怀疑是 apache与tomcat之间的问题。 检查tomcat的性能状态与工作日志。 Tomcat的busy线程数无法超过20。即同时处理的请求 数不超过20。 apache端日志会出现503错误，mod jk日志中会出现 “can't find free endpoint”错误。 打开mod_jk配置，发现cache size的值设为20。 查阅此参数的说明，worker.properties文件中的 worker.worker1.cachesize=xx和 worker.worker1.cache_timeout=xx两个选项在apache 1.2.16之后的版本已经废弃，但如果使用将仍然生效。当大 用户量时，apache的mod jk维持的连接数不会超过 cachesize值，否则将抛出错误，反映在apache端，为503 错误。
Query cache hit rate Query cache size Query cache limit Replication status Times behind master Queries inserts/ deleted / updated/ selected
观察进程内存利用情况时， 下面两项指标非常重要：
Operating System memory constraints Permanent memory anomalies
◦ Process memory utilization
掌握数据库主要性能指 标
◦ Connection statistics
使用过滤器来过滤特定的事务状态、事务名称、 group、Vuser等 可以使用全局过滤器也可以针对某张图使用过滤器 可以对过滤器使用条件或者，对数据进行过滤
Web服务器较慢一般 有如下原因：
◦ 负载过高 ◦ 配置不当 ◦ 其他问题
测试期间对web服务 器进行监控可以帮助 排查性能问题
性能测试结果
50用户在线访问
80用户在线访问
用户量越大，效率越高。即并发量越大，效率越 高。 ② 响应时间的差别主要体现在js的获取时间上 进一步分析， ① Js是静态资源，需要考虑tomcat对静态资源处理 的机制。 ② 根据访问特点（1），极有可能和缓存有关。 下一步方向， ① 查看tomcat的缓存机制
JVM参数设置太小，为512M，调整为1.6G后，问题解决。
性能监控Top 10 性能分析基础知识
J2EE架构性能监控Top 10
掌握应用程序端统计指标
◦ 响应时间
平均、最大、最小、90%、标准差
◦ 并发数 ◦ Hits per second ◦ 在线用户 ◦ 吞吐量 ◦ 常见错误
◦ Connection pools
◦ Caches
Hit count Miss count
Java虚拟机性能度量
◦ Heap performance
Heap utilization Heap growth pattern Garbage collection behavior
周保玉
Loadrunner结果分析 深入分析性能数据 案例分析
Explain the value of results analysis Diagnose errors with LoadRunner Interpret LoadRunner graphs to derive meaningful results by drilling down to root cause problems
Time to First Buffer is the period between a browser request and the first reply. Provides high level Server vs. Network determination
识别消耗时间最多 的页面，找出时间 都花费在哪些功能 上 可用隔离分析DNS 问题、SSL问题、连 接问题
Open connections Aborted connections Threads used Threads in cache
◦ Key efficiency
Key hit rate Key buffer used Key buffer size
◦ Query statistics ◦ Query cache hit rate
Component metrics
例子:
Our load testing goal is to be able to support 100 users with < 5 second transaction response time across all transactions Any issues that affect this should be identified and resolved
从负载增长情况和服务器的资源情况，可以进一步得到结论： 正是应用服务器的问题，导致了系统不能支持更大的负载。
检查错误日志/访问日 志
wenku.baidu.com
检查垃圾回收
可以发现堆内 存的使用持续走高， 达到最大值，造成 jvm内存短缺 。进 一步造成处理能力 下降，最终的表现 是连接堆积过多， 响应时间迅速变大。
背景 查看系统是否支持600人在线，各事务的响应时间在 12s以内 环境部署： 2台web，一台认证服务器，一台应用服务器 (tomcat) 6台mysql数据库服务器（一主5从）
在线人数达到550人时，响应时间突然变大
查看服务器资源，寻找趋势异常的服务器。CPU LOADAVERAGE 图与CPU 使用率图。Loadrunner的资源监控图线告诉我们，在响应时间异常的点，应 用服务器出现了性能问题。CPU average突然上升到42，CPU使用率也急剧 上升，达到60%以上，正常状态下为9%。
正常负载范围内， server的CPU 使 用率一般不应高 于70%. 运行期间，可用 的物理内存不应 太低
随着压力的增长，如果某个指标的曲线开始变得平坦， 往往意味着极限或者瓶颈已经出现。
在不断增长的负载下，如果连接数曲线开始变得平坦，往往意味web server端的问题 在不断增长的负载下，如果吞吐量图线开始变得平坦，往往意味着网 络带宽达到极限
排查过程：
• 查看主机资源 – 正常 • 查看数据库慢查询日志 – 找到慢sql
掌握App server性能度量主要参数
◦ Thread pools
Thread pool utilization Queue depth Request throughput Connection pool utilization Execute threads awaiting for a connection
单位时间内的访问数
单位时间内发送的请求数
掌握操作系统性能指标
◦ CPU
User time, sys time, io wait, idle Load average
◦ DISK IO ◦ NETWORK
磁盘读写速率、队列情况
网络读写速率
◦ MEMORY
Free, buffer, cache, swap
◦ Thread details
◦ Table lock statistics
Immediate locks Locks wait
◦ Replication details
连接池案例 Session案例 缺少索引案例 Tomcat缓存案例 MCPACK内存泄露
性能问题 在压力测试过程中，并发数上不去，web服务器、 应用服务器和数据库服务器资源都处于较低使用状 态。
Details transaction response throughout the test Identifies problematic transactions Identifies problematic points in the test
Details transaction response time as a function of load Identifies under what load conditions transaction times begin to degrade
性能测试期间能够收集的性能数据数量是惊人的。 因此，如果没有足够的技巧来处理这些数据，诊 断性能问题是不可能的。 LoadRunner Analysis的能力:
• 对数据进行过滤，隐藏不想看到的数据，突出重点关 注的数据 • 通过合并、自动关联等重新组织特定的数据，突出数 据间的联系 • Drill-Down capability
Details transaction response time as a service level Identifies percentage of transactions complete over time
Details transaction response time as a distribution count Identifies number of transactions complete over time
常用命令
◦ Top, vmstat, iostat, mpstat
◦ Swap
Used , free Si, so
◦ System
In, cs
Apache的性能度量
◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ Total Accesses 总的访问量 Total KBs 总的吞吐量 CPU Load CPU负载百分数 Uptime 启动以来的时间 Requests Per Second 每秒请求数 Bytes Per Second 每秒字节数 Bytes Per Req 每个请求的byte数 Busy Workers 处于busy状态的线程数 Idle Workers 处于idle状态的线程数