基本概念
　　开始前，先简单介绍一下性能测试的几个基本概念。
　　并发数
　　并发数是指在同一个时间点，同时请求服务的客户数量。
　　比如大家常说的：『 我的网站可以承受一万并发。 』在通常情况下指的是：如果同时有一万名用户访问网站，所有人都可以正常获得服务。而不会有超时或连接拒绝情况发生。
　　吞吐率
　　吞吐率指的是服务处理请求的效率，计算方式为 （ 总处理请求数 / 总耗时 ）。
　　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)