基本概念
开始前，先简单介绍一下性能测试的几个基本概念。
并发数
并发数是指在同一个时间点，同时请求服务的客户数量。
比如大家常说的：『 我的网站可以承受一万并发。 』在通常情况下指的是：如果同时有一万名用户访问网站，所有人都可以正常获得服务。而不会有超时或连接拒绝情况发生。
吞吐率
吞吐率指的是服务处理请求的效率，计算方式为 （ 总处理请求数 / 总耗时 ）。
HTTP 服务的吞吐率通常以 RPS（Requests Per Second 请求数每秒）作为单位。吞吐量越高，代表服务处理效率就越高。换句话说就是网站的性能越高。
注意：吞吐率和并发数是两个完全独立的概念。拿银行柜台来举个例子，并发数指同时有多少人往银行柜台涌来。吞吐率则指银行柜台在一段时间内可以服务多少个人。
但是在性能测试中，二者之间通常会呈现出一种关联关系。当并发数增大时，吞吐率通常也会随之上升（ 多用户发挥出并行处理优势） 。但在并发数超过某个边界值后，吞吐率则会下降 （用户过多，花在上下文切换的开销急剧增大，又或者内存消耗过多） 。
响应时间
响应时间指的是用户从发出请求到接收完响应之间的总耗时，它由网络传输耗时、服务处理耗时等多个部分组成。通常以毫秒（ms）作为单位。
与并发数的关系：一般来说，随着并发数增大，单个用户的响应时间通常会随之增加。这很好理解，餐馆吃饭的人越多，单个顾客等待的时间就越长。
与吞吐率的关系：更高的吞吐率通常意味着更低的响应时间。因为吞吐率是以 单位时间 内的请求处理能力来计算的。
平均响应时间与百分位响应时间
平均响应时间指的是所有请求平均花费的时间，如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms。那么平均响应时间为 (98 * 1 + 2 * 100) / 100.0 = 2.98ms 。
百分位数（ Percentile - Wikipedia ）是一个统计学名词。以响应时间为例， 99% 的百分位响应时间 ，指的是 99% 的请求响应时间，都处在这个值以下。
拿上面的响应时间来说，其整体平均响应时间虽然为 2.98ms，但 99% 的百分位响应时间却是 100ms。
相对于平均响应时间来说，百分位响应时间通常更能反映服务的整体效率。现实世界中用的较多的是 98% 的百分位响应时间，比如 GitHub System Status 中就有一条 98TH PERC. WEB RESPONSE TIME 曲线。
准备工作
1. 挑选测试目标
一个网站通常有很多个不同的页面和接口。如果要完全模拟真实环境的访问，就得为各页面设置不同的权重，同时访问所有页面。或者取巧一点，采用重放真实环境访问记录的方式。
进行整体性能测试比较复杂，这里不打算介绍相关内容。 这次主要讨论对单个页面测试。
那么，怎么挑选测试的目标页面呢？一般来说，那些用户访问较多的页面通常是比较好的选择，它们可能是：
· 首页/Landing Page ：通常是用户第一个打开的页面
· 关键行为页面 ：如果网站的主要功能是发放优惠券，那就测试发放优惠券的接口
· 活动页面 ：新活动上线推广前，理所应当应该进行性能测试
尽量模拟真实的用户情况
举个例子，如果你想压测一个文章列表页，那么一定先要挑选一位拥有一定数量文章的用户，然后使用其身份来进行测试。千万不要用那些一篇文章没有、或只有少数文章的测试账号。那样会产生失真的测试结果，让你对服务能力产生过于乐观的估计。
所以，在测试与用户相关的动态内容时，请细心挑选用户身份，尽量反映绝大多数用户的情况。
别忘了关注边界情况
让测试过程反映绝大多数用户的情况很重要，但也请别忘了那些边界情况。
比如，当用户拥有 50 篇以下的文章时，你的文章列表页面响应速度非常好，吞吐率非常高。那么如果某个用户拥有 1000 篇文章呢？列表页的性能表现还能满足需求吗？响应时间会不会呈指数级上升？这些都是你需要测试的。
牢记『木桶效应』，你的服务很可能会因为没有处理好这些边界情况而崩溃。
2. 选择测试工具
市面上开源的 HTTP 性能测试工具非常多，我使用过的就有 wrk 、 ab 、 vegeta 、 siege 等。所有工具都支持对单个地址进行测试，部分工具支持通过地址列表进行批量测试。
除了 ab 这种历史比较悠久的工具，大部分现代压测工具效率都非常高，所以挑选哪个区别不大。像我就是 wrk 的粉丝。
3. 记录关键信息
硬件配置对测试结果影响非常大。所以，在开始测试前，最好记录下你的服务器硬件情况，这包括 CPU、内存、网卡速度等等。如果有必要的话，那些关键的关联服务 - 比如数据库 - 的硬件配置也应该一并记录下来。
除了硬件配置外，还应该记录下与你的服务密切相关的其他配置信息，比如：
· 服务 Worker 类型是什么？线程、协程或是进程？开启了多少个？
· 是否使用数据库连接池
等等等等。当你对比多份测试结果时，这些配置信息就会派上用场。如果你还想分享测试结果给他人，那么提供这些配置信息是必须的。
进行压测
接下来就可以开始具体的压测过程了。一般来说，针对单页面的压测过程都是非常简单的。你只需要提供少数几个参数：并发数、持续时间、页面地址，然后等待测试完成即可。以 wrk 为例：
$ wrk --latency -c100 -t5 -d 10 http://localhost:8080/hello/piglei
# -c 100：使用 100 个并发数
# -t 5：开启 5 个线程
# -d 10：持续 10 秒钟
一份完整的测试报告，通常要覆盖多个不同的并发数配置，比如 [10, 100, 256, 512, 1024, 2048] 等等。你最终的测试结果，需要体现出服务在不同并发数下的性能表现差异。
在压测过程中，还有几个注意点：
1. 专机专用
执行测试工具的机器与测试目标服务所在的机器上，最好不要运行其他无关的程序。这样可以最大程度减小对测试结果的影响。
2. 测试时间不要过短
缓存需要预热，服务也需要一段时间来稳定下来。所以，测试时间不要太短，比如小于 30 秒钟。过短的测试时间会影响结果的可靠性。
为了让测试结果更可靠，请让每次测试时间至少超过一分钟，比如 3-5 分钟。
3. 不要让测试机成为瓶颈
现在的服务器配置越来越强大，很有可能，你的目标服务处理能力还没达到瓶颈。你的测试机就已经先不行了。所以，在测试过程中，请一并关注你的测试机负载情况。
如果发现因为测试机自身瓶颈导致测试结果不准确，请使用更好的机器，或尝试同时使用多台测试机。
4. 调整好系统参数
在开始压测前，确保系统的最大文件描述符数量等参数已经被调优过，避免影响压测过程。详见： Linux Increase The Maximum Number Of Open Files / File Descriptors (FD)
查看压测结果
以下是执行 wrk 后的输出结果：
Running 10s test @ http://localhost:8080/hello/piglei
5 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 336.28ms 651.93ms 1.72s 81.42%
Req/Sec 657.74 547.89 3.47k 72.81%
Latency Distribution
50% 28.88ms
75% 38.64ms
90% 1.71s
99% 1.72s
33320 requests in 10.00s, 4.10MB read
Requests/sec: 3331.92
Transfer/sec: 419.74KB很少人会反对提高软件开发质量的需求。使用软件的技术人员已经开始预估各种各样的故障和缺点，特别是在个人计算机世界里，我们认为频繁出现问题是完全正常的并且在意料之中。尽管如此，随着软件开发日趋成熟，我们开始对如何在质量方面作出必要改进有了进一步的理解。
什么是测试管理？
软件质量一个很重要的部分就是测试和验证软件有效性的流程。测试管理是组织和控制测试工作所需的流程和工件的实践。用于测试管理的传统工具包括：
• 笔和纸
• 字处理程序
• 电子数据表
更大的测试工作可以使用自己开发的软件测试管理解决方案，通常建立在电子数据表或数据库或者像 IBM® Rational® ClearQuest® Test Manager 或者 Mercury TestDirector 这样的商业测试管理应用软件的基础之上。
测试管理的整体目标是允许团队在整个软件开发工作里计划、开发、执行并评估所有的测试活动。这包括调整测试工作中包含的所有工作，跟踪测试资产中的依赖关系和相互关联，并且最重要的是对质量目标进行定义、测量和跟踪。
测试管理的各个方面
测试管理可以被分成几个不同的阶段：组织、计划、创作、执行以及报告。这些在下面有更详细的描述。
测试工件和资源组织是测试管理中显然必不可少的部分。这需要组织和维持测试项目的详细目录，以及用来执行测试的各类事物。这表现了团队如何跟踪测试资产中的依赖关系和相互关联。需要管理的测试资产中最普遍的类型是：
• 测试脚本
• 测试数据
• 测试软件
• 测试硬件
测试计划是回答为什么测试、测试什么、在哪里测试和什么时间测试这些问题的全部任务设置。创建一个特定测试的原因被称作一个测试激发因素（例如，必须确定一个特定的必要条件）。为了一个项目需要被测试的内容被分成许多的测试用例。在哪里测试通过决定和记录所需的软件和硬件配置来回答。什么时间测试通过跟踪测试的迭代（或者循环，或者时间周期）来解决。
测试创作是获得完成给定测试所需特定步骤的过程。它回答了如何测试的问题。这里是一些稍微抽象的测试用例被分成更详细的测试步骤的地方，这些步骤将变成测试脚本（要么是人工生成，要么自动生成）。
测试执行通过将测试脚本的顺序集合成测试套件来运行这些测试。这是对如何测试这一问题的后续回答（更为准确地说，是如何管理这些测试）。
测试报告是指如何对测试工作的不同结果进行分析和沟通。这用来决定项目测试的当前状态和应用软件或系统的质量的整体水平。
测试工作将产生大量的信息。在这些信息里，可以提取为项目定义、度量及追踪质量目标的方法。不管使用什么沟通机制，这些质量度量方法需要被传递给其他项目作为测试度量的基础。
测试产生的一个非常普通的数据类型是缺陷，它通常是质量度量方法的来源。缺陷不是静态的，而是随着时间在变化。此外，多种缺陷总是互相关联的。有效的缺陷跟踪对测试和开发团队来说都是十分重要的。
测试管理中的其他因素
除了软件和硬件测试工件和资源以外，必须管理 测试团队。测试管理必须调动致力于团队工作的所有团队成员的积极性。这需要对测试人员和工件控制 用户安全和进入许可。对于那些跨越一个或更多场所或团队的项目（这将迅速成为规范）来说，这也包括组织场所和团队协调。
一个项目的特定测试流程对于测试管理来说意义十分明显。对于一个迭代的项目，测试管理将必须提供基础并重复地指导计划、执行和测试评估。而后，测试策略也将必须遵循测试管理框架。
相关的软件开发规程
虽然软件开发中所有的过程都与测试相关联，有几个与测试的关系尤为重要：
• 需求管理
• 变更管理
• 配置管理
需求管理是大多数测试工作的先驱，提供了大量的测试动机和确认需求。一个项目特定的需求管理流程对测试管理流程有重要影响。这种关系类似于一场接力赛，第一个跑的人代表着需求管理，下一个接受接力棒的人代表测试管理。IBM® Rational® RequisitePro®是发现、记录、组织和跟踪需求说明的工具。更多的信息可以在 IBM® developerWorks®Requisitepro 资源页面上找到。
变更管理影响软件开发的全部过程，但是被跟踪的与测试工作最相关的变更是缺陷。缺陷是测试与开发之间最常见的主要通信渠道。从缺陷得出的计算和方法也经常被用作质量度量方法。ClearQuest 是一种贯穿整个软件开发周期中用于管理诸多类型的变更和活动的强大的、高可配置的工具。更多的信息可以在 IBM® developerWorks®ClearQuest 资源页面上找到。
配置管理对于测试管理来说很重要，因为在什么时候对哪一个要测试的版本进行跟踪对测试来说至关紧要。配置管理为测试执行控制着由测试管理跟踪的工作版本和环境。IBM® Rational® ClearCase® 是主要的配置管理工具。更多的信息可以在 IBM® developerWorks®Clearcase 资源页面上找到。
测试管理的挑战
总结测试管理目标的一个方法是回答下面的问题：
• 为什么我应该测试？
• 我应该测试什么？
• 我在哪里测试？
• 我什么时候测试？
• 我如何指导测试？
从高层次的角度来看，这可能十分简单，但是在典型的软件开发中总会出现许多障碍。下面详细描述这些挑战。
没有足够的时间来测试
除了某些专门的或者任务十分重要的应用程序外，很少的软件项目在开发周期里拥有充足的时间完成高水平的质量度量。通常情况是，软件工程里本来就很短的“测试周期”总是不可避免地会被耽搁。即使是最好的项目也很有可能在测试工作上面临时间限制。在测试管理中这种障碍的影响是不断变换优先级，不断转换工作以及为测试结果和质量检测方法简化数据。
没有足够的资源来测试
除了缺少时间外，通常在取得执行必要的测试所需的合适资源方面也面临困难。资源可能被其他工作或项目分享。虽然测试的硬件资源会带来延迟和困难，但是人力资源的缺乏可能更加难以解决。在测试管理中这种障碍的影响和时间缺乏造成的影响大致相同。
测试团队并不是总在一个地方
这段时期更经常的情况是测试资源可能可以获得，但是它们不在同一个地方。在各地区协调人力以降低成本已成为家常便饭，但是这造成相当多的技术障碍。在另一区域的团队如何共享工件并保持协同合作，并不会造成延迟和影响整个团队的和谐？一个项目如何能将区域分布式开发的效率发挥到极至呢？
需求方面的难题
虽然有许多的测试策略，但是确认需求是需要完成的最主要的、优先级最高的测试工作。做到这一点需要完整的、明确的和可测试的需求。不够完美的需求管理会导致测试工作中更大的问题。使用像 RequisitePro 这样的工具可以帮助极大地提高需求管理并促进有效需求的开发。
对于有效的测试管理来说，必须有对于最新系统变更和业务需求的无缝接口。这种接口必须不只是针对需求的描述，也要针对优先级、状态和其他属性。此外，这需要开发需求说明的团队和执行测试的团队之间最大限度的协调分工和沟通。这种沟通必须在确保质量的所有方面进行。
与开发保持同步
软件质量所需的另一种团队协作存在与测试人员与开发人员之间的。除了关键缺陷之外，软件开发中总有一个惯例，那就是测试团队的工作只有测试人员关注。尽管如此，对于每一个人，特别是对开发人员来说了解当前的质量水平以及哪些已经被测试、哪些还没有被测试是十分重要的。
为了有效地使用他们的宝贵时间，测试团队必须跟上不断变化的代码、工作版本和环境。测试管理必须精确识别要测试的工作版本和测试的合适的环境。测试错误的工作版本（或功能）会导致时间的浪费，并严重地影响项目进度。测试人员必须也了解什么缺陷是已知的，不需要重新测试的以及哪些是需要确定的。而后测试人员必须将已发现的缺陷以及促进解决方案的充分信息提供给开发人员。
报告正确信息
如果能够为项目传达测试状态和一些质量评定标准，测试工作只是有用的。得出报告十分简单，但是提供恰当的信息（在合适的时间，为合适的人）是更加由意义的，主要有以下的原因：
• 如果只有非常少的信息，那么除了对测试团队来说减少了感知缺陷的价值外，项目涉众将不能充分了解影响质量的问题。
• 如果有过多的信息，那么主要信息的意义和影响就变得模糊。
• 在如何将信息与不同地方的不同角色分享上总是有技术障碍。
报告结果的另一个需要考虑的事项是如何安排信息以及以采用什么形式（也就是说，信息是基于工具的、基于浏览器的还是基于文件的形式）。如果有技术上或者其他限制报告的安排或形式上的约束，项目涉众对于测试和质量信息的了解将被减少。数据应该以一种清晰有逻辑的设计方式呈现出来，表示适当的意义，而不是以受局限的工具或技术的方式。因此对于项目管理来说在提供宽泛的报告格式方面考虑适应性和接受力的需要是十分重要的。
什么是质量度量？
测试团队的一个主要目标是评估并决定质量，但是如何准确地度量质量呢？有许多的方法可以实现，而且根据系统或应用软件的类型和开发项目的特殊性分为很多不同的种类。为了避免曲解，任何一个质量度量方法都是需要清晰明确的。更重要的是，测试方法必须可以获取和保存，否则它们可能不值得花费成本或者可能是不完整或者不准确的。
测试管理的建议
下面是可以提高软件测试管理的一般建议。
尽早开始测试管理活动
虽然这一点看起来像最显而易见的建议，但是很少软件项目真正地应用这一观念。在早期开始确定测试资源很容易而且很常见，但是许多测试分析（如识别关键的、优先的测试用例）可以而且应该尽快开始。一旦用例被充分开发产生事件流，就可以得到测试程序。如果一个项目没有使用用例需求，那么仍可以从确认初始需求说明中得到测试。尽快开发测试能帮助减轻未来不可避免的时间限制。
迭代化测试
软件测试应该是一个反复的过程，在整个项目周期的早期生成有价值的测试工件和工作。这是遵循尽早开始测试流程的首要建议：一个迭代的测试流程应该很早就关注测试管理。测试管理通过组织迭代的各类工件和资源来指导这一点。这个基于风险的方法有助于确保以最有效的方式处理项目时间线里可能出现的变更、延迟和其他一些不可预见的障碍。
重用测试工件
在一个项目或多个项目里重用测试工件能够极大地提高测试团队的有效性。这样可以极大地缓解时间和资源有限造成的压力。可以重用的工件不仅包括自动操作测试对象，还包括测试程序和其他的计划信息。为了有效地重用工件，测试管理必须在组织和描述给定项目的与测试相关的各种信息方面做得很好。在创建工件时，重用总是需要一些预先计划，而且这一原则通常可以应用于测试管理。
使用基于需求的测试
测试可以被分成两种常用的方法：
• 确认事情按照计划进行
• 尽力找出什么使得事情停止下来
虽然后面的探索性测试对于发现导致错误的难以预测的场景或情形来说非常重要，但是确认基本的需求可能是测试团队执行的最重要的评估。
基于需求的测试是确认一个应用软件或系统的主要方式，它既适用于传统需求也适用于用例需求。基于需求的测试往往没有探索性测试那么主观，它也可以带来其他的益处。软件开发团队的其他部分可能质疑或者谴责探索性测试的结果，但是他们不能怀疑直接确认需求的测试。另一个好处是它可以更容易地计算所需的测试工作（与探索性测试相反，它总是受限于可以利用的时间）。
它也可以提供各类统计数据，他们可能是有用的度量，例如测试覆盖率。测试用例是由需求产生的，并且随着事情变化对其关系的跟踪也更为重要，这是一件复杂的工作，应该通过工具进行处理。RequisitePro 和 ClearQuest 中的测试管理能力提供了满足这一需求的结果方案。
这一流程的局限性是它信赖于一个好的系统需求和一个十分有效的合理的需求管理计划。从另一方面来说，探索性测试可能更加特殊。它很少依赖软件开发团队的其他部分，这有时会导致测试工作很少被关注在确认需求的重要任务上。虽然较好的测试工作应该将不同的方法集成起来，但是不应该忽视基于需求的测试。
协调远程测试资源
为了避免资源不足或者只是为充分利用人员，您应该协调可以运用的任何资源，不管它们在什么地方。这些重要的资源很可能存在于多种区域，通常在不同的地方。这需要仔细有效的协同合作使得各地区的大多数测试人员和其他人参与到测试管理中。为了使之生效可能有相当多的技术挑战，因此需要适当的处理。ClearQuest 的 MultiSite 版本的测试管理能力能够帮助简化区域分布式测试协调的复杂度。
我应该使用 Web 客户还是自动复制的数据呢？有两种解决方案使得相距较远的参与者能够协同工作。前者简单并且相对容易，但是如果从各地进行访问，仍有网络方面的潜在约束。对于受到人员或者功能限制的远程访问来说，这是一个好的解决方案。但是，对于由许多不同地方的人组成一个测试团队的情况，您需要具有复制到本地服务器上的数据使得他们的运行速度达到最大化。这也意味着您将需要一个简单无缝的方式使得每个地方的数据自动同步。这是 ClearQuest MultiSite 对于测试管理来说十分重要的地方。
定义并执行灵活的测试流程
一个好的、可重复的流程能够帮您了解项目的当前状态，并通过预测了解其趋势。尽管如此，不同的项目对测试工作将有不同的特定需要，因此使得工作流程自动化的测试管理流程需要是灵活的并且可以定制的。流程应该是可重复的（为了提供预测），但是更重要的是，它必须允许改进。它必须使得修正十分容易，包括在迭代项目过程中的调整，因此它可以通过改变需要使其达到最优。
如果不能以任何方式执行，那么定义一个指导团队成员的带有工作流程的过程意义并不大。需要怎样的力度来执行根据不同的企业和项目而有所不同。许多企业的软件项目需要遵循不同的法规，如 SOX 和 HIPPA。有些需要变更审核、项目历史和其他像电子签名等严格的遵守确认。不管您的项目测试管理需要严格地执行流程还是有更多的临时选择，您都需要一个机制来定义和执行某些事情。像 ClearQuest 这样测试管理工具是能够提供测试管理所需的所有能力。
调整并整合开发的剩余部分
从传统意义来看，软件测试与开发的其他部分是严格分开的。这样做部分源于保持评估公正和有更多的机会发现开发中可能没有察觉的缺陷的合理需要。这一需要在验收测试中尤为明显，因为在验收测试中最好的测试人员往往对设计和执行因素缺乏判断力。尽管如此，这种特定需要仅仅代表软件测试中的一个方面，不应该对最终要进行的软件质量开发制造障碍。
软件测试必须与软件开发的其他部分结合起来，特别是像需求管理和变更管理这样的规程。这包括不同的流程角色和活动之间重要协作、重要信息的高级沟通以及支持这一点的集成工具。没有这些协同分工，质量将会由于缺少或误解需求、没有测试代码、没有发现缺陷和缺少关于现行软件质量水平的信息而降低。
沟通状态
工作的价值等取决于它被认知的程度，而工作如何被认知取决于传递给涉众的信息。好的测试管理必须提供所有相关信息的完整和正确的报告。在软件开发项目里实时状态、目标的测量方法以及结果应该提供给所有相关的团队成员。
报告应该不仅仅只是传统意义的静态文件。假定变化是持续的，为了准确地交流信息需要有多种形式的易更新的输出。所有这些会帮助不同的项目角色在随着项目的进展对变化如何做出反应方面做出正确的决策。
来自不同的软件规程的信息不是完全独立的。这篇文章已经提到了测试管理和其他像需求、变更和配置管理和开发这样的规程之间的重要关系。因此来自测试管理的输出可以很容易地与其他项目数据结合起来是至关重要的。当前的技术使得将所有的项目方法结合成为统一视图成为可能，这样可以确定所有项目的健康状态。工具也使得清楚地展示和评估测试、开发和其他项目工件的关系成为可能。
关注目标和结果
为项目确定质量目标并决定如何有效而准确的测量这些目标。测试管理是详细说明目标、用于测量这些目标的方法以及将如何收集这些数据的地方。测试中许多工作可能没有明显的完成标准。定义正在进行的流程和变更的特定输出和测量方法将更详细地说明测试工作的活动和任务。牢记测试的特定目标和测试方法不仅有助于跟踪状态和结果，还能避免最终将所需报告混在一起。
在一个单一的、公共的知识库或数据库储存测试管理的结果以确保更加容易地对他们进行分析或使用。这也促进了工件（包括工作）的版本控制，避免出现过时或无效信息的问题。这一切将有助于项目成员了解流程并在测试工作的基础上做出决策。
通过自动化来节约时间
测试管理的内容有很多，而且许多工作非常耗时。为了节约时间，可以使用工具让许多工作自动化，或者至少半自动化。虽然像字处理程序和电子数据表这样的简单的工具提供了很大的灵活性，但是专门用于测试的自动化工具更加有效，更加有助于节约时间。通过自动化收益极大的工作包括：
• 跟踪需求测试和其他测试激发因素的关系
• 组织和重用测试用例
• 记录和组织测试配置
• 计划和协调各种工作版本和应用软件的测试执行
• 计算测试覆盖率
• 各种各样的报告工作
在测试管理中对适当工作的使用工具以使其自动化将极大地提高其价值和收益。
来自 <https://www.ibm.com/developerworks/cn/rational/products/testingsolutions/testmgmt.html>
在一次压测结果中，有很多有用的指标：
· 吞吐率 Requests/sec： 服务吞吐能力，也就是一秒钟平均处理多少请求数。它通常是压测结果中最重要的指标。
· 数据传输速率 Transfer/sec： 数据传输速率，压测响应结果较大的页面时，请尤其注意该值有没有达到网络瓶颈。
· 响应时间 Latency： 有关响应时间有很多不同值，请不要只关注平均响应时间，更需要注意最小值、最大值、百分位值、标准差等等。
· 错误请求数： 当并发数过高，或服务处理能力不够时。请求就可以发生错误。你的服务可以最多承受多少并发而不产生错误？这是需要重点关注的指标之一。
可能影响压测结果的因素
1. HTTP 响应是否开启 Gzip 压缩
如果目标服务处在 Nginx 等支持 gzip 压缩的服务后，而刚好请求响应体又比较大。那么是否开启压缩会较大程度影响到压测结果。每个工具开启压缩的方式都不一样，一般情况下，你需要手动添加 Accept-Encoding: gzip, defalte 请求头来开启 Gzip 压缩。
2. 测试机器与目标服务之间的网络质量
测试机器和目标服务之间的网络状况会很大程度影响压测结果。所以，最好保证测试机与目标服务处在同一网段。同时关注压测结果中的数据传输速度（Transfer/sec）是否接近网络速率极限值。
3. 负载均衡器
如果你的目标服务前面有配置负载均衡器，那么它可能会对测试结果产生影响。
比如，使用 Nginx 的 proxy_pass 配置的后端服务，极限 RPS 在几千左右。如果后端服务的吞吐率非常高，那就需要考虑负载均衡器会不会成为你测试的瓶颈所在。
4. 是否开启了 HTTP 长连接
较现代的 HTTP 服务器基本都支持持久化连接（以前俗称 keep-alive），在测试过程中，请确定你的测试工具与服务端是否都开启了 HTTP 长连接选项。
因为每次压测通常要产生非常多次请求，客户端的连接是否可以复用对结果影响非常大。可以的话，请将开启或关闭长连接作为两种情况分开测试。
来自 <http://www.51testing.com/html/94/n-3715994.html>