性能测试结果的分析原 则：具体问题具体分析（ 这是由于不同的 应用系统，不同的 测试目的，不同的性能 关注点）查找瓶颈时按以下 顺序，由易到 难。服务器硬件瓶 颈- 网络瓶颈（对局域网，可以不考 虑）- 服务器操作系 统瓶颈（参数配置） -中间件瓶颈（参数配置， 数据库，web服务器等） - 应用瓶颈（SQL 语句、数据库设计 、业务逻辑 、算法等）注：以上 过程并不是 每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我 们分析到 应用系 统在将来大的 负载压 力（并发用户数、数据量）下，系统的硬件瓶 颈在哪儿就 够了。性能测试结 果分析中，分段排除法很有效分析的信息来源：1）根据 场景运行 过程中的 错误提示信息2）根据 测试结 果收集到的 监控指标数据一性能 测试结 果的错误提示分析分析实例：1）Error: Failed to connect to server “payment.baihe.com : 10060 Connection Error: timed out Error: Server “user.baihe.com has shut down the connection prematurely 分析：A、应用服务死掉。（小用 户时：程序上的 问题。程序上 处理数据库的问题）名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 5 页 - - - - - - - - - B、应用服务没有死（应用服务参数设置问题）例：在 许多客户端连接 Weblogic 应用服务器被拒 绝，而在服 务器端没有 错误显 示，则有可能是 Weblogic 中的 server 元素的 AcceptBacklog 属性值设得过低。如果 连接时收到connection refused消息， 说明应提高该值，每次增加 25C、数据 库的连接(1 、在应用服务的性能参数可能太小了 2 、数据 库启动的最大 连接数（跟硬件的内存有关）) 2）Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成A、应用服务参数设置太大 导致服务器的瓶 颈B、页面中图片太多C、在程序 处理表的 时候检查字段太大多二性能 测试结 果的监控指标数据分析1最大并 发用户数：应用系统在当前 环境（硬件 环境、网 络环境、 软件环境（参数配置）下能承受的最大并发用户数。在方案运行中，如果出 现了大于 3 个用户的业务 操作失 败，或出 现了服务器 shutd own的情况， 则说明在当前 环境下，系 统承受不了当前并 发用户的负载压 力，那 么最大并 发用户数就是前一个没有出 现这种现 象的并 发用户数。如果测得的最大并 发用户数到达了性能要求，且各服务器资源情况良好， 业务操作响 应时间也达到了用 户要求，那 么 OK 。否则，再根据各服 务器的资源情况和 业务操作响 应时间进一步分析原因所在。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 5 页 - - - - - - - - - 2业务操作响 应时间 ：分析方案运行情况 应从平均事 务响应时间图 和事 务性能摘要 图开始。使用“事 务性能摘要”图，可以确定在方案 执行期间响应时间过长 的事务。细分事务并分析 每个页面组件的性能。 查看过长的事务响应时间 是由哪些 页面组件引起的？问题是否与网 络或服务器有关？如果服 务器耗时过长 ，请使用相 应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网 络耗时过长 ，请使用“网 络监视 器”图确定导致性能瓶 颈的网络问题2-5-10 原则：简单说 ，就是当用 户能够在 2 秒以内得到响 应时，会感 觉系统的响应很快；当用 户在 2-5 秒之间得到响 应时，会感 觉系统的响应速度还可以；当用 户在 5-10 秒以内得到响 应时，会感觉系统的响应速度很慢，但是 还可以接受；而当用 户在超过 10 秒后仍然无法得到响 应时，会感 觉系统糟透了，或者 认为系统已经 失去响 应，而选择离开这个Web站点，或者 发起第二次 请求. 3服务器资源监控指标：内存：1）UNIX 资源监控中指 标内存页交换速率（Paging rate），如果 该值偶尔走高，表明当时有线程竞争内存。如果持 续很高， 则内存可能是瓶 颈。也可能是内存 访问命中率低。2）Windows资源监控中，如果 ProcessPrivate Bytes计数器和 ProcessWorking Set计数器的 值在长时间内持续升高，同 时 MemoryAvailable bytes计数器的 值持续降低， 则很可能存在内存泄漏。内存资源成为系统性能的瓶颈的征兆 : 很高的 换页率(high pageout rate); 进程进入不活 动状态; 交换区所有磁 盘的活动次数可高 ; 可高的全局系 统 CPU 利用率 ; 内存不 够出错(out of memory errors) 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 5 页 - - - - - - - - - 处理器：1）UNIX资源监控（Windows操作系 统同理）中指 标 CPU 占用率（ CPU utilization），如果该值持续超过 95% ，表明瓶 颈是 CPU 。可以考 虑增加一个 处理器或 换一个更快的 处理器。如果服 务器专用于 SQL Server, 可接受的最大上限是80-85% 合理使用的范 围在 60% 至 70% 。2）Windows资源监控中，如果 SystemProcessor Queue Length大于 2，而处理器利用率（Processor Time ）一直很低， 则存在着 处理器阻塞。CPU资源成为系统性能的瓶 颈的征兆 : 很慢的响 应时间 (slow response time) CPU空闲时间为 零(zero percent idle CPU) 过高的用户占用 CPU 时间(high percent user CPU) 过高的系统占用 CPU 时间(high percent system CPU) 长时间 的有很 长的运行 进程队列(large run queue size sustained over time) 磁盘 I/O ：1）UNIX资源监控（Windows操作系 统同理）中指 标磁盘交换率（Disk rate），如果 该参数值一直很高，表明 I/O 有问题。可考 虑更换更快的硬 盘系统。2）Windows资源监控中，如果 Disk Time和 Avg.Disk Queue Length的值很高，而Page Reads/sec 页面读取操作速率很低， 则可能存在磁 盘瓶径。I/O 资源成为系统性能的瓶 颈的征兆 : 过高的磁盘利用率 (high disk utilization) 太长的磁盘等待队列(large disk queue length) 等待磁 盘 I/O 的时间所占的百分率太高 (large percentage of time waiting for disk I/O) 太高的物理 I/O 速率:large physical I/O rate(not sufficient in itself) 过低的缓存命中率 (low buffer cache hit ratio(not sufficient in itself) 太长的运行 进程队列，但 CPU 却空闲(large run queue with idle CPU) 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 5 页 - - - - - - - - - 4数据库服务器：SQL Server 数据库：1）SQLServer资源监控中指 标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于 80% ，应考虑增加内存。2）如果 Full Scans/sec（全表 扫描/ 秒）计数器显示的值比 1 或 2 高，则应分析你的查询以确定是否确 实需要全表 扫描，以及 SQL查询是否可以被 优化。3）Number of Deadlocks/sec(死锁的数量/ 秒) ：死 锁对应 用程序的可伸 缩性非常有害，并且会 导致恶劣的用 户体验。该计数器的 值必须为 0。4）Lock Requests/sec(锁请求/ 秒) ，通过优化查询 来减少 读取次数，可以减少 该计数器的值。Oracle 数据库：1）如果自由内存接近于0 而且库快存或数据字典快存的命中率小于0.90 ，那么需要增加 SHARED_POOL_SIZE的大小。2）如果数据的 缓存命中率小于 0.90 ，那么需要加大 DB_BLOCK_BUFFERS参数的 值（单位：块）。3）如果日志 缓冲区申 请的值较大，则应加大 LOG_BUFFER参数的 值。4）如果内存排序命中率小于0.95 ，则应加大 SORT_AREA_SIZE以避免磁 盘排序 。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 5 页 - - - - - - - - -