后台性能测试规范-世界视点

参考资料

• ISO25010
• IEEE 829
• 29119
• 书籍《Performance Testing An ISTQB Certified Tester Foundation Level Specialist Certification Review.epub》

目的

规范云平台性能测试，包括测试指标、测试过程、性能分析等。

(相关资料图)

测试指标

本指标适用于使用性能测试进行性能测试项目技术质量评价依据，规范技术测试结果评价，统一性能测试技术测试质量度量。应用系统技术质量度量指标范围广泛，本文难以涵盖全部，仅供实际测试参考定制使用。 预期读者为测试管理人员、测试实施人员、技术支持人员、项目管理人员等系统技术质量相关人员。

系统性能指标

• 响应时间 Response Time: RT

响应时间指用户从客户端发起请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量，单位一般为秒或毫秒。平均响应时间指系统稳定运行时间段内，同一交易的平均响应时间。一般而言，交易响应时间均指平均响应时间。 平均响应时间指标值应根据不同的交易分别设定，一般情况下，分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。其中，特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性。

1秒以下为佳，部分复杂业务3秒以下。

• 吞吐量（系统处理能力）

系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。 系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般的建议与系统交易日志保持一致，以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标。

一般情况下，用以下指标来度量：HPS（Hits Per Second） ：每秒点击次数，单位是次/秒。TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。

无论TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：1000 TPS~50000 TPS

• 并发用户 Virtual User：VU

并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。 并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各种情况相关。例如系统吞吐能力很强，加上短连接一般都有连接复用，往往并发用户数大于系统的并发接入连接数。

一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来。

• 错误率 Virtual Failure Ratio：FR: VU

错误率指系统在负载情况下，失败交易的概率。错误率＝（失败交易数/交易总数）×100%。稳定性较好的系统，其错误率应该由超时引起，即为超时率。

不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%。

资源指标

• CPU Central Processing Unit：CPU

中央处理器是一块超大规模的集成电路，是计算机的运算核心（Core）和控制核心（ Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。CPU Load：系统正在干活的多少的度量，队列长度。系统平均负载。

CPU指标主要指的CPU使用率、利用率，包括用户态（user）、系统态（sys）、等待态（wait）、空闲态（idle）。CPU使用率、利用率要低于业界警戒值范围之内，即小于或者等于75%、CPU sys%小于或者等于30%，CPU wait%小于或者等于5%。单核CPU也需遵循上述指标要求。CPU Load要小于CPU核数。

• 内存 Memory

内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。

现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%，太多的交换将会引起系统性能低下。

• 磁盘吞吐量 Disk Throughput

磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据，一般情况下，磁盘繁忙率要低于70%。

• 网络吞吐量 Network Throughput

网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。

网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。

• 内核参数

操作系统内核参数主要包括信号量、进程、文件句柄，一般不要超过设置的参数值即可，具体如下：

中间件指标

常用的中间件例如Tomcat、Weblogic等指标主要包括JVM、ThreadPool、JDBC，具体如下：

当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置50和最大值设置200比较合适。

当前运行的JDBC连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC最小值设置50和最大值设置200比较合适。

GC频率不能频繁，特别是FULL GC更不能频繁，一般情况下系统性能较好的情况下，JVM最小堆大小和最大堆大小分别设置1024 M比较合适。

数据库指标

常用的数据库例如ＭySQL指标主要包括SQL、吞吐量、缓存命中率、连接数等，具体如下：

SQL耗时越小越好，一般情况下微秒级别。命中率越高越好，一般情况下不能低于95%。锁等待次数越低越好，等待时间越短越好。

稳定性指标

最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。 一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于7×24运行的系统，至少应该能够保证系统稳定运行24小时以上。 如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。

TPS曲线稳定，没有大幅度的波动。各项资源指标没有泄露或异常情况。

批量处理指标

指批量处理程序单位时间内处理的数据数量。一般用每秒处理的数据量来衡量。处理效率是估算批量处理时间窗口最重要的计算指标。 关于批量处理时间窗口，不同系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同一系统内部，也可能存在多个批量处理过程同时进行，其时间窗口相互叠加。 长时间批量处理将会对联机在线实时交易产生重大的性能影响。

在数据量很大的情况下，批处理时间窗口时间越短越好。不能影响实时交易系统性能。

可扩展性指标

指应用软件或操作系统以集群方式部署，增加的硬件资源与增加的处理能力之间的关系。计算公式为：（增加性能/原始性能）/（增加资源/原始资源）×100%。 扩展能力应通过多轮测试获得扩展指标的变化趋势。 一般扩展能力非常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好。

理想的扩展能力是资源增加几倍，性能就提升几倍。扩展能力至少在70%以上。

可靠性指标

• 双机热备

  • 节点切换是否成功及其消耗时间。
  • 双机切换是否有业务中断。
  • 节点回切是否成功及其耗时
  • 双机回切是否有业务中断。
  • 节点回切过程中的数据丢失量。在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。

• 集群

  • 集群中某个节点出现故障时，系统是否有业务中断情况出现。
  • 集群中新增一个节点时，是否需要重启系统。
  • 故障节点恢复后，加入集群，是否需要重启系统。
  • 故障节点恢复后，加入集群，系统是否有业务中断情况出现。
  • 节点切换需要多长时间。在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。

• 备份和恢复：本指标为了验证系统的备份、恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：

  • 备份是否成功及其消耗时间。
  • 备份是否使用脚本自动化完成。
  • 恢复是否成功及其消耗时间。
  • 恢复是否使用脚本自动化完成指标体系的运用原则。
  • 指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
  • 部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
  • 对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
  • 如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
  • 测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。

性能测试的过程

• 测试需求得到批准
• 数据已获批准
• 性能测试计划已获批准
• 测试工具经POC可用
• 业务流程清单已批准
• 测试环境
• 测试脚本
• 测试方案
• 测试监控

测试计划

测试计划包含测试环境、测试数据、风险分析、工具和人力资源等内容，具体内容可以基于IEEE829和ISO 29119定制。

为了完成性能测试计划，通常需要进行如下活动。

• 研讨会

开发、产品、项目、测试等聚在一起，性能工程师告知项目的利益相关者关于性能测试的基本规则、要求和程序。

• 业务和技术概述

性能工程师要清楚地了解应用/基础设施的性质（软件、硬件、协议、业务流程和所需数据）。在这一点上，性能工程师可以强调系统中任何早期的潜在性能弱点，并提前告知可能需要关于这些弱点的更多信息。

• 需求/用户故事的定义

结合需求/用户故事，可以得出明确的成功标准（对于需求和用户故事，因为两者都需要一个可衡量的方法来知道最终的测试是否会通过）。

• 接口列表

• 模型分析（目标）

构建一个真实世界的使用模型。这些应该基于平均、峰值和最坏的情况（周末、月末、季末、或财政年或日历年末，或明年或五年后的预期峰值）。模型使性能工程师能够确定哪种性能测试情景适合即将进行的性能测试。这些场景将与前面提到的性能要求/用户故事和风险相关联。

• 性能测试工具分析/概念验证

几乎在每一种情况下，性能测试都需要工具。有大量的商业和开放源码的工具，选择正确的工具会使性能测试更容易。需要注意的是，没有一种工具是适合所有情况的，也没有一种工具对任何情况都是完美的。

• 性能项目规划（时间表Schdule）

规划过程中的最后一步是确定性能项目的时间线。从整个项目的时间表和完成日期开始，向后推算，性能测试的测试计划阶段可以被记录下来。还需要进一步的细节，但在这一点上，它将给出一个估计性能测试时间表的总体情况。在这一点上，生成一个甘特图来添加到性能测试计划中是很有用的。还应该记住，计划过程中总是会遗漏任务或可能发生的随机事件，但随着经验的积累（或可能是以前的性能测试计划的 "复制"），这种情况可以减少。

• 性能测试计划让项目等相关人员参与到性能测试计划的审查中来是合适的。这份文件成为性能测试项目的预期结果，从利益相关者那里得到反馈，以确保性能测试的目标/目的和整个项目的目标/目的都能实现。

小结：测试计划定义了性能测试范围、测试环境、测试数据、工具和所需的人力资源，并完成了风险识别和分析。其输出是一个更新的项目测试计划和/或性能测试计划。

性能测试项目检测与控制

注意这里提到的监测是指监测性能测试项目的进展，而不是在性能测试期间进行的监测。

控制是为了在遇到可能影响性能效率的问题时提供行动计划，例如：

• 如果基础设施不能按计划为特定的性能测试产生所需的负载，则增加负载生成能力
• 改变、新建或更换硬件
• 网络组件的变化
• 软件实施的变化

对性能测试目标进行评估，以检查退出标准的实现情况。

测试分析

有效的性能测试是基于对性能要求、测试目标、服务水平协议（SLA）、IT架构、流程模型和其他构成测试基础的项目的分析。这项活动可以通过使用电子表格或容量规划工具对系统资源需求和/或行为进行建模和分析来支持。

具体的测试条件被确定，如负载水平、时间条件和要测试的事务。然后决定所需的性能测试的类型（例如，负载、压力、可扩展性）。

a.测试用例和脚本设计

测试是由测试条件、测试用例和测试程序这三个部分组成的。

b.测试场景设计

充分考虑：

• 需求/用户故事
• 业务流程
• 性能风险
• 选择的性能工具
• 数据规模
• 项目范围和约束

充分结合负载测试、压力测试、可扩展性测试、尖峰测试、耐久性测试、并发测试、容量测试等

1. 前面提到的性能测试类型
2. 虚拟用户的总数和用户组之间的分布情况
3. 要测试的业务流程
4. 负载模型--虚拟用户登录的速度（上升），测试的持续时间，以及虚拟用户如何注销（下降）。
5. 业务流程中细分的交易总数
6. 在性能测试期间，任何需要添加到负载中的后台工作。

c.监控设计

软件、硬件和基础设施将决定如何进行监控，而需求/用户故事将决定所需的监控量。需要考虑的事情包括：

• 所选择的性能和监控工具 - 一个工具是否能涵盖所有需要的监控，还是需要多个工具？

• 结果存储 - 需要多少存储空间来存储结果集，以及这些工具是否能够访问这个存储区域？

• 安全访问 - 性能监测工具是否能够访问所需的计数器进行监测？

• 所需的指标 - 既要考虑默认的指标集，又要考虑与性能测试要求及需求相关的具体指标。

d.数据计划

性能测试可能需要几百个用户做几十个迭代，需要几万个输入数据记录，并将数据填充到性能测试环境中。

e.时间表

最后一步是为性能测试的创建和执行创建一个更详细的低级别的时间表。这个时间表不仅要考虑何时创建和运行性能测试，还要考虑由谁来创建和运行。前面创建的甘特图可以用较低层次的细节来显示逐日计划，包括在这个阶段计划的具体性能测试的创建和随后的执行。

小结：性能测试是基于对测试基础的分析（性能要求、测试目标、服务级别协议、IT架构、流程模型和其他项目），由系统资源要求和/或行为的建模和分析来支持。具体的测试条件，如负载水平、时间条件和要测试的事务，决定了性能测试的类型（例如，负载、压力、可扩展性）。

测试设计

此步实现详细的性能测试用例与脚本。脚本要遵循公司编程规范。

a.数据准备主数据、用户定义的数据、事务性数据

b.测试实现脚本实现。

注意点

• 手动执行脚本
• 参数化
• 关联
• 检查点
• 计时
• 迭代并发执行

测试执行

此步将性能测试用例代码化并执行。

a.环境搭建检查软硬件列表、网络等。

b.测试执行运行性能测试，确保适当的控制是到位的，以允许有意义的结果。这听起来很明显，但令人惊讶的是，在执行前经常忘记一些事情，导致无效的结果和时间的浪费。性能测试通常是循环进行的--可能有一个或若干个性能测试，将针对代码/应用/系统的一个版本/构建来执行。

c.结果分析

d.中期测试报告每次测试后，应写一份结果总结。中期报告应该是对测试目标成功或失败的简短总结（一封电子邮件或一页报告）。如果你正在进行上百个测试，这可能是不可能的；显然，为每个测试写一份报告是不现实的，为一个测试周期写一份报告可能更合适。

重要的是，这个总结将给相关者提供一个关于目标的观点，以便根据需要做出决定。更深层次的分析可以包含在这份报告中，或者可能需要几个执行周期来确定更深层次的问题。

e.补救措施（如果需要的话）在每个性能测试执行完成后，应该有一个决定点，决定测试是否完成得令人满意。补救工作可以集中在脚本（改变或更新），测试数据（改变或刷新），基础设施，或被测系统。任何补救工作都必须被记录下来。

f.测试周期报告在一个性能测试周期完成时，应完成一份测试周期报告。这比中期测试报告更全面，包含了中期测试报告中没有包括的额外信息。在这一点上，可以对该周期内的测试和早期执行的周期进行性能比较。

g.结果审查会议这个会议的目的是与相关者（包括技术和商业）一起分析结果。在这一点上相关者可以利用审查会议的信息，对性能测试项目做出明智的决定。

性能工程师：

• 证明性能测试已经成功执行。
• 识别新的潜在性能风险。
• 识别并展示测试计划的任何变化。
• 显示所进行的任何补救工作。
• 显示任何进一步改进系统和过程的机会。

h.系统和过程的改进这包括对系统的改进（调整）和对性能过程的改进。只有在未完成的性能项目风险仍然需要进一步缓解时，才会进入这一状态。目标应该是改善性能测试过程和/或正在遵循的程序。一旦完成，这个过程就会循环到最初的测试设置。

小结：测试执行运行性能测试；对结果进行评估，看系统的性能是否符合既定目标，并报告任何缺陷。

测试完成

性能测试结果在测试总结报告中提供给相关者。测试结果通过指标来表达，这些指标经常被汇总以简化测试结果的含义。仪表盘等可视化的报告手段经常被用来表达性能测试结果，比基于文本的指标更容易理解。

a.测试完成报告测试完成报告是对测试周期报告与性能测试计划的整合。它不仅提供了所执行的测试周期的信息，而且详细说明了性能测试项目和产品的风险，发现的缺陷，以及如何缓解这两者。

b.介绍和建议

在会议上向项目利益相关者介绍调查结果和建议可能会更容易。这允许利益相关者澄清他们不理解的任何要点。这个阶段对于让性能测试和性能工程师给那些出席这次会议的利益相关者一个积极的印象是极其重要的。性能工程师必须考虑业务和技术知识的差异--可能需要召开两次会议。一个好的做法是，在第一次会议上提供业务信息，但不提供技术细节，并在随后的会议上与相关的书呆子进行技术细节上的 "深入探讨"。

小结：性能测试结果在测试总结报告中提供给相关者，显示为指标和仪表盘汇总，以简化测试结果，让利益相关者理解。

性能分析

性能分析的前提

性能分析的前提除了需要丰富的性能测试监控（如客户侧监控、基础类监控、应用类监控），还需要具备相关的技术知识（包括但不限于：操作系统、中间件、数据库、开发等）。

性能分析的流程

很多情况下压测流量并没有完全进入到后端（服务端），在网络接入层（云化的架构，例如：SLB（Server Load Balancer）/WAF（Web Application Firewall）/高防IP，甚至是CDN（Content Delivery Network）/全站加速等）可能就会出现由于各种规格（带宽、最大连接数、新建连接数等）限制或者因为压测的某些特征符合CC（Challenge Collapsar）和DDoS（Distributed Denial of Service）的行为而触发了防护策略导致压测结果达不到预期。接着看关键指标是否满足要求，如果不满足，需要确定是哪个地方有问题，一般情况下，服务器端问题可能性比较大，也有可能是客户端问题（这种情况非常小）。对于服务器端问题，需要定位的是硬件相关指标，例如CPU，Memory，Disk I/O，Network I/O，如果是某个硬件指标有问题，需要深入的进行分析。如果硬件指标都没有问题，需要查看中间件相关指标，例如：线程池、连接池、GC等，如果是这些指标问题，需要深入的分析。如果中间件相关指标没问题，需要查看数据库相关指标，例如：慢查SQL、命中率、锁、参数设置。如果以上指标都正常，应用程序的算法、缓冲、缓存、同步或异步可能有问题，需要具体深入的分析。

可能瓶颈点

• 硬件、规格上的瓶颈

一般指的是CPU、内存、磁盘I/O方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）。

• 中间件上的性能瓶颈

一般指的是应用服务器、web服务器等应用软件，还包括数据库系统。 例如：中间件weblogic平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。

• 应用程序上的性能瓶颈

一般指的是开发人员开发出来的应用程序。 例如，JVM参数不合理，容器配置不合理，慢SQL，数据库设计不合理，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够、无缓冲、无缓存、生产者和消费者不协调等），造成系统在大量用户访问时性能低下而造成的瓶颈。

• 操作系统上的性能瓶颈

一般指的是Linux等操作系统。 例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。

• 网络设备上的性能瓶颈

一般指的是防火墙、动态负载均衡器、交换机等设备。当前更多的云化服务架构使用的网络接入产品：包括但不限于SLB、WAF、高防IP、CDN、全站加速等等。 例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。

方法

CPU资源利用率很高的话，需要看CPU消耗User、Sys、Wait哪种状态。如果CPU User非常高，需要查看消耗在哪个进程，可以用top（linux）命令看出，接着用top –H –p 看哪个线程消耗资源高。如果是Java应用，就可以用jstack看出此线程正在执行的堆栈，看资源消耗在哪个方法上，查看源代码就知道问题所在；如果是c++应用，可以用gprof性能工具进行分析。如果CPU Sys非常高，可以用strace（linux）看系统调用的资源消耗及时间。如果CPU Wait非常高，考虑磁盘读写了，可以通过减少日志输出、异步或换速度快的硬盘。

操作系统为了最大化利用内存，一般都设置大量的cache，因此，内存利用率高达99%并不是问题，内存的问题主要看某个进程占用的内存是否非常大以及是否有大量的swap（虚拟内存交换）。

磁盘I/O一个最显著的指标是繁忙率，可以通过减少日志输出、异步或换速度快的硬盘来降低繁忙率。

网络I/O主要考虑传输内容大小，不能超过硬件网络传输的最大值70%，可以通过压缩减少内容大小、在本地设置缓存以及分多次传输等操作提高网络I/O性能。内核参数一般都有默认值，这些内核参数默认值对于一般系统没问题，但是对于压力测试来说，可能运行的参数将会超过内核参数，导致系统出现问题，可以用sysctl来查看及修改。

JVM主要分析GC/FULL GC是否频繁，以及垃圾回收的时间，可以用jstat命令来查看，对于每个代大小以及GC频繁，通过jmap将内存转储，再借助工具HeapAnalyzer来分析哪地方占用的内存较高以及是否有内存泄漏可能。简单点可以使用APM工具，例如阿里云ARMS。

如果线程不够用，可以通过参数调整，增加线程；对于线程池中的线程设置比较大的情况，还是不够用可能的原因是：某个线程被阻塞来不及释放，可能在等锁、方法耗时较长、数据库等待时间很长等原因导致，需要进一步分析才能定位。

JDBC连接池不够用的情况下，可以通过参数进行调整增加；但是对于数据库本身处理很慢的情况下，调整没有多大的效果，需要查看数据库方面以及因代码导致连接未释放的原因。

SQL效率低下也是导致性能差的一个非常重要的原因，可以通过查看执行计划看SQL慢在哪里，一般情况，SQL效率低下原因主要有：

调优

调优步骤a.确定问题

• 应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。
• 数据库配置：经常引起整个系统运行缓慢，一些诸如大型数据库都是需要DBA进行正确的参数调整才能投产的。
• 操作系统配置：不合理就可能引起系统瓶颈。
• 硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。
• 网络：网络负载过重导致网络冲突和网络延迟。b.分析问题
• 当确定了问题之后，我们要明确这个问题影响的是响应时间吞吐量，还是其他问题？
• 是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不同？
• 系统资源监控的结果是否正常？CPU的使用是否到达极限？I/O情况如何？
• 问题是否集中在某一类模块中？
• 是客户端还是服务器出现问题？ 系统硬件配置是否够用？
• 实际负载是否超过了系统的负载能力？ 是否未对系统进行优化？
• 通过这些分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。

c.确定调整目标和解决方案高系统吞吐量，缩短响应时间，更好地支持并发。

d.测试解决方案对通过解决方案调优后的系统进行基准测试。（基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试）。

e.分析调优结果系统调优是否达到或者超出了预定目标；系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题；调优是否可以结束了。 最后，如果达到了预期目标，调优工作可以先告一段落。

调优注意事项

• 在应用系统的设计开发过程中，应始终把性能放在考虑的范围内，将性能测试常态化，日常化的内网的性能测试+定期的真实环境的业务性能测试，PTS都可以支持。
• 确定清晰明确的性能目标是关键，进而将目标转化为PTS中的压测场景并设置好需要的目标量级，然后视情况选择并发、TPS模式，自动递增/手工调速的组合进行流量控制。
• 必须保证调优后的程序运行正确。
• 系统的性能更大程度上取决于良好的设计，调优技巧只是一个辅助手段。
• 调优过程是迭代渐进的过程，每一次调优的结果都要反馈到后续的代码开发中去。
• 性能调优不能以牺牲代码的可读性和可维护性为代价。