企业官网建设流程全解析

1. 极简压测工具的设计思路，为什么一个文件就够用

做后端开发这几年，压测工具我用过不少，从 Apache Bench 到 wrk、JMeter，各有各的脾气。但真正让我停下来琢磨的，是 colibri 这个项目。原因很简单，它整个核心就两个文件，加起来大约 1200 行代码，却能把性能压到网卡上限。这种“极简到极致”的风格，在一堆动不动就要装环境、写配置文件的重量级方案里，显得特别扎眼。

colibri 是法语里“蜂鸟”的意思，体型小、振翅快，用它给压测工具命名很贴切。它解决的核心问题是：在不需要复杂分布式、不需要海量机器的情况下，单机能不能把目标服务的压力打上去？传统思路里，很多人觉得压测必须上多线程、多进程，线程越多并发越高。但 colibri 用 Python 的 asyncio 和 aiohttp 证明了另一条路——用协程和异步 I/O，单线程也能堆出很高的吞吐量。

这个项目适合谁参考？我觉得分两类人。一类是后端开发，想搞明白自己的接口到底能扛多少 QPS，但又不想为了压测去学一整套专业工具；另一类是刚接触异步编程的人，想找一个结构清晰、能读懂的实战项目，看看协程在真实场景里是怎么把网络 I/O 利用率拉满的。因为我实际改过、跑过类似方案，所以这篇就顺着 colibri 的设计思路，把我自己的实践过程、踩过的坑、调参经验都过一遍。代码量不大，但里面涉及异步模型、网络 I/O 调度、资源约束这些点，弄明白之后你再看其他压测工具，思路会通不少。

1.1 极简背后的取舍逻辑

先说 colibri 的设计哲学：能不做的事就不做。很多压测工具功能齐全，但也意味着概念多、配置多、学习成本高。colibri 放弃了插件系统、放弃图形界面、放弃复杂的报告模板，只保留一件事：尽可能快速地把请求发出去，然后把响应数据记录下来。它选择 Python 而不是 Go 或 C++，看起来反直觉，因为大家默认压测性能就该上编译型语言。但这里有个关键判断：如果你的目标是“模拟真实用户请求”，瓶颈通常不在客户端 CPU，而在网络延迟和带宽。异步 I/O 让 Python 在等待网络响应时能切去处理其他请求，只要并发协程数量够多，单机照样能产生巨大压力。

另一个关键取舍是使用 aiohttp 而不是 requests。requests 是同步库，同一时刻一个线程只能等一个请求回来，要模拟高并发就得开大量线程。线程多了之后，操作系统上下文切换的开销会逐渐压过实际请求的开销，线程池管理也变得繁琐。aiohttp 是异步库，配合 asyncio 的事件循环，用一个进程就能管理成千上万个连接，数据结构上也更贴近底层 socket 的行为。实际测试下来，同样的机器、同样的目标接口，异步方案的吞吐量是同步多线程方案的几倍到几十倍，尤其是在请求带 100ms 以上网络延迟的时候，差距更明显。

还有一点值得提，colibri 允许把测试结果进一步转发到 Kafka 做分析。也就是说它本身不搞复杂图表，而是把原始数据推出去，让懂数据分析的人自己处理。一开始可能觉得功能缺失，但仔细想，压测数据的消费方式本来就很多样：有人要看实时曲线，有人要做历史对比，有人要报警监控。与其在压测工具里堆一堆用不上的图表功能，不如把数据开放出去，各取所需。这种思路在开源项目里其实蛮有代表性——核心做薄，接口做开放，反而适用面更广。

1.2 网上对 colibri 的常见误解

我在一些技术社区里看到过对这类异步压测方案的讨论，发现有几个观点流传得比较广，但实际并不准确。第一个说法是“Python 写的压测工具性能肯定不行”，这种判断太粗糙了，性能瓶颈不在语言本身，而在 I/O 模型。如果你的机器配置足够、网络带宽足够，Python 异步压测完全可以跑满一条千兆网卡，这时候瓶颈反而是目标服务而不是客户端。

第二个常见的误解是“并发数越高越好”。实际上当并发协程数超过某个值之后，吞吐量会进入一个平台期，继续增加并发，反而会带来更多的调度开销和资源争抢。我记得自己跑过一次测试，并发从 200 提到 1000，QPS 不但没涨，还因为文件描述符和内存占用增加出现了明显回落。好的压测方式不是无脑堆并发，而是找到当前环境下的“甜点区间”。

第三个误解是“压测工具只要能发请求就行”。只关心发请求的量和速度，不关心响应状态码分布、响应时间分位数、错误率变化，这些数据才是定位问题的关键。colibri 这类工具会采集响应状态、耗时信息并输出记录，目的就是让你在压出高吞吐的同时，还能判断服务是否在被压的过程中出现了非预期错误。单纯追求 QPS 数字好看，在实际调优中意义不大。

2. 核心细节解析：异步压测的原理和关键参数

要真正用好这类极简压测工具，光会敲命令行是不够的，得把背后的原理捋清楚。其实异步压测的本质没那么玄乎，我尽量用大白话讲明白里面几个关键机制，顺带把我调参的经验也写进来。

2.1 协程和异步 I/O 是怎么把并发“跑”起来的

传统同步模型里，一个请求从发出到收到响应，整个链路中大部分时间都花在“等待”上——等待 DNS 解析、等待 TCP 握手、等待服务端处理、等待响应数据传回。单线程发一个请求，接着就在那儿干等，CPU 完全空闲。多线程模型解决了一部分问题，但每个线程都有独立的栈空间和调度状态，线程数量一多，操作系统需要频繁地保存和恢复上下文，这个开销会被不断放大。

asyncio 的协程模型思路不太一样。它不是把任务分配给操作系统管理的线程，而是在一个线程内部，用一个事件循环来调度无数个协程任务。当协程发起网络请求后，如果暂时拿不到结果，就主动把执行权交还给事件循环（也就是 await 一个可等待对象），事件循环这个时候会去执行其他已经就绪的协程。网络事件到达后，系统再通过回调或者 Future 对象把协程唤醒。这样整个过程中，CPU 一直处于高频工作状态，没有干等的时间。

用一个生活化的类比——同步模型就像银行只有一个柜台，客户排队办理业务，一个人在窗口前填单子，后面人全部等着；异步模型则是客户进门先取号，轮到的时候才去窗口，等待期间可以去喝茶、填其他资料，柜员只要闲下来就能服务下一个人。取号的“号”，就是 asyncio 里的 future 对象，而“叫号系统”，就是事件循环。理解这个类比之后，再看 colibri 里的代码结构就顺畅了：它一次循环创建大量协程任务，每个任务负责一个请求的全部生命周期，await 点就是让出 CPU 的地方。

2.2 aiohttp 连接池和会话复用：为什么不要每个请求新建连接

aiohttp 是 colibri 压测能力的基石，但 aiohttp 用起来有个特别容易踩的坑：很多人会在循环里反复创建 ClientSession 对象，这在压测场景下会变成灾难。ClientSession 内部维护的是连接池（默认单主机最大 100 个连接），如果你每次都 new 一个 Session，那等于每次都创建一套全新的连接池，底层意味着反复完成 TCP 握手、TLS 协商这些开销很大的流程。压测工具本身要追求把流量打满，而不是把时间浪费在握手协商上，正确的做法是启动时创建好 Session，整个压测过程复用同一个实例。

连接池本身也有参数值得关注：limit 控制到同一个主机的最大并发连接数，limit_per_host 则是单主机维度上的限制。在 aiohttp 里，这两个参数决定了同一时刻能有多少个连接在传输数据。我之前有一次压测本机服务，怎么调并发都上不去，后来发现是 aiohttp 客户端默认 limit=100 卡住了总连接数，事件循环里大量协程在排队等待连接释放。把 limit 调到 500 甚至更高之后，吞吐量立刻上了一个台阶。

另外，HTTP 长连接（Keep-Alive）在压测中是默认成立的，因为 aiohttp 的 Session 会复用底层连接。但要注意目标服务器上的连接超时配置，如果服务端设的 Keep-Alive 超时短于压测的请求间隔，连接会被服务端主动关闭，这时客户端会看到 ConnectionResetError 或相似错误。排查这类问题的思路不是去看压测工具配置，而是去抓包确认连接是否被远端 reset。

2.3 并发数与延迟、吞吐量的关系：甜点区间怎么找

在压测里有个基本关系：当并发请求持续到达时，吞吐量（QPS）、并发数（C）、平均延迟（L）满足一个近似公式：C = QPS × L。也就是说，如果你想让 QPS 提升，无非两条路：提高并发数，或者降低延迟。延迟由服务端处理能力和网络决定，你控制不了太多；所以压测时你能直接调的就是并发数。

但并发数不是越大越好的。刚开始增加并发时，吞吐量会线性上升，因为网络 I/O 还没打满，有更多请求在“路上”。到达某个临界点后，吞吐量增速放缓，延迟开始快速升高。再继续加并发，事件循环调度开销、内存压力、目标服务的连接数上限，都会成为新的瓶颈，吞吐量甚至可能掉头向下。找一个具体的项目来举例：假设目标接口平均响应时间是 50ms，那么理论上 200 个并发协程最多能产生 200 / 0.05 = 4000 QPS 的吞吐量。如果你的目标 QPS 是 10000，那并发数至少得 500 以上。这个公式判断量级非常方便，我每次压测前会先拿它估算一下，再决定从哪里开始设置并发。

实际操作里找甜点区间的方法是阶梯加压：从较小的并发数开始，比如 50，每跑 30 秒记录一组吞吐量和延迟数据，然后翻倍到 100、200、400，观察曲线变化。当延迟开始明显抬升但吞吐量几乎不再增长时，那个点附近的并发数就是当前环境的甜点区间。真实环境中不要一次就拉到很高并发，一个是容易把目标服务打挂影响线上业务，另一个是数据上你也看不出瓶颈到底在哪。

2.4 超时、重试和数据统计：容易忽略的三个细节

超时配置在压测工具里往往被忽略，但它的重要性不亚于并发数。如果你不设超时或者超时时间设置过长，一旦目标服务出现假死（连接建立了但迟迟不返回响应），大量请求会堆积在等待队列中，事件循环可能被这些“僵尸请求”拖垮。真实环境中我踩过这样的坑：某个接口在高并发下偶发卡顿，单次请求要等 10 秒以上，结果压测客户端自身的内存和连接池先爆掉了，压测结果完全失真。在 colibri 这类工具里，socket 的 read timeout 设置要考虑目标接口的正常响应时间，一般比 P99 响应时间大个两三倍就差不多。如果你对延迟分布没把握，可以先小并发跑一轮，看看 P99 是多少再定。

重试逻辑也是双刃剑。有些压测工具为了追求请求成功率，在失败之后自动重试。从压测的角度看，这反而会掩盖服务的问题——到底是网络抖动导致失败，还是服务端真的扛不住了？高并发下重试还会造成“重试风暴”，让本来已经吃紧的服务雪上加霜。我倾向于在压测场景里关闭自动重试，让失败的请求如实反映到错误率统计里，这样数据才有参考价值。

数据统计环节要重点关注的不是平均值，而是分位数。平均值在长尾分布下毫无意义：假设 99% 的请求都是 20ms 返回，剩下 1% 的请求因为 GC 停顿或排队等了 2 秒，平均值也会被拉得很高，但这个高平均值反映的不是普遍现象。P95、P99 才能告诉你“绝大多数用户的真实体验是什么样”。colibri 会把每次请求的状态码和耗时记录保留下来，方便事后自己算分位数，这个设计在实际排查问题时帮了我不少忙。

3. 实操过程：从零复刻一个 colibri 风格的压测脚本

前面讲的都是原理，这节我直接给出一套可以运行的代码，并配合详细说明。为了让演示更完整，这里我以一个简单的 HTTP 压测脚本为例，从环境准备到参数选择、从跑出数据到分析结果，全部走一遍。这套代码并不是 colibri 的逐行复刻，但设计思路和它保持一致，你可以把它当成一个 sqb 版本的精简实现来用。

3.1 环境准备和基础依赖安装

先明确一下运行环境。我用的是 Python 3.10，Linux 系统，一台普通的 4 核 8G 云主机做压测客户端。在开始写代码之前，有几个系统层面的限制需要提前调整，否则后面一定会踩坑。

第一个是文件描述符限制。Linux 默认情况下，单个进程能打开的文件描述符数量是 1024。压测时一个连接对应一个 socket，也就是一个文件描述符，并发 1000 就至少要 1000 个文件描述符。不调这个限制，程序跑着跑着就会报 “Too many open files”。调整方法是用 ulimit 命令，例如 ulimit -n 65535，但是这个调整只对当前 shell 会话有效。更规范的做法是修改 /etc/security/limits.conf，为指定用户或进程组设置 nofile 上限。

第二个是内核网络参数。如果是为了压测本机或者同机房的服务，建议把临时端口范围扩大，避免端口耗尽。可以用 sysctl -w net.ipv4.ip_local_port_range="1024 65535" 临时调整，要持久化就写进 /etc/sysctl.conf。另外，TIME_WAIT 状态的连接如果过多，也会占用端口资源，可以酌情缩短 net.ipv4.tcp_fin_timeout，但不能设置得太短，否则可能影响连接可靠性。

然后是 Python 依赖，只需要两个：aiohttp 和 aiohttp 的辅助库。安装命令很简单，用 pip 装好 aiohttp 就行。如果你需要把数据推送到 Kafka，那还需要对应的客户端库，不过这次演示我们先不涉及。

3.2 编写压测脚本主体代码

下面这一段是压测脚本的核心。代码主要分成三块：命令行参数解析、压测逻辑、结果输出。为了让代码可读性更好，我按功能拆了几个函数：

import asyncio import argparse import time import statistics from collections import defaultdict import aiohttp async def worker(session, url, results, worker_id, request_count): """每个 worker 协程负责发 request_count 个请求，并把每笔请求的耗时和状态码记录下来。""" for i in range(request_count): start = time.perf_counter() try: async with session.get(url) as resp: await resp.read() status = resp.status except Exception as e: status = f"error: {type(e).__name__}" cost_ms = (time.perf_counter() - start) * 1000 results.append((status, cost_ms)) async def run_load(url, concurrency, total_requests, timeout, keepalive): conn = aiohttp.TCPConnector(limit=concurrency, limit_per_host=concurrency, force_close=False) timeout_ctx = aiohttp.ClientTimeout(total=timeout) results = [] tasks = [] # 每个协程平均分到一定数量的请求 per_worker = max(1, total_requests // concurrency) async with aiohttp.ClientSession(connector=conn, timeout=timeout_ctx) as session: for w_id in range(concurrency): tasks.append(asyncio.create_task(worker(session, url, results, w_id, per_worker))) await asyncio.gather(*tasks) return results def print_report(results, concurrency): status_counter = defaultdict(int) latencies = [] for status, cost_ms in results: status_counter[status] += 1 if str(status).isdigit(): latencies.append(cost_ms) latencies.sort() total = len(latencies) if total == 0: print("没有成功的请求，检查服务地址或网络") return mean = statistics.mean(latencies) p50 = latencies[int(total * 0.50)] p95 = latencies[int(total * 0.95)] p99 = latencies[min(int(total * 0.99), total - 1)] qps = total / (sum(latencies) / 1000) # 这里有更准确的计算方式，下面会说明 print(f"并发数: {concurrency}") print(f"请求总数: {total}, 错误数: {total - status_counter.get(200, 0)}") print(f"QPS(估算): {qps:.2f}") print(f"平均延迟: {mean:.2f} ms") print(f"P50: {p50:.2f} ms") print(f"P95: {p95:.2f} ms") print(f"P99: {p99:.2f} ms") print("状态码分布:", dict(status_counter)) if __name__ == "__main__": parser = argparse.ArgumentParser(description="极简异步压测脚本") parser.add_argument("url", help="目标URL") parser.add_argument("-c", "--concurrency", type=int, default=100) parser.add_argument("-n", "--requests", type=int, default=10000) parser.add_argument("-t", "--timeout", type=float, default=10) args = parser.parse_args() total = args.requests concurrency = args.concurrency # 让总请求数是并发数的整数倍，避免有的协程多跑有的少跑 if total % concurrency != 0: total = (total // concurrency + 1) * concurrency print(f"压测目标: {args.url}, 并发: {concurrency}, 总请求: {total}") results = asyncio.run(run_load(args.url, concurrency, total, args.timeout)) print_report(results, concurrency)

3.3 关键参数选择与计算过程

这段代码有一个细节值得展开讲讲，就是 per_worker 的计算方式。它把总请求数按并发数平均分配，每个协程负责固定数量的请求，最后用 asyncio.gather 等待所有协程完成。为什么不做一个共享的队列，让空闲协程去队列里取任务呢？两种方式都能实现，但平均分配的方式在数据统计上更简单，协程之间的负载非常均衡，不会出现某些协程早早做完、另一些还在拼命跑的情况。缺点是如果某些请求延迟特别高，整个测试的收尾时间会被最慢的那个协程拖住。实际上因为这个场景里所有请求都是同质的，平均分配完全够用。

超时参数 timeout_ctx 用的是 aiohttp.ClientTimeout(total=timeout)，这里设置的是整个请求的总超时，包含连接建立和响应读取的时间。如果你的目标接口有网络延迟抖动，建议设成 10 秒起步。如果目标服务是本地接口，可以适当缩短到 5 秒，避免个别卡死的请求阻塞聚合过程太长时间。

连接池两个参数 limit 和 limit_per_host 都设成并发数，意味着允许建立的连接数量和并发任务数一致。这样每个协程拿到一个独立的连接，不会出现协程等待空闲连接的情况，压力模型更接近“固定并发连接数”。如果你不设这个参数，aiohttp 默认连接上限是 100，并发超过 100 时新增协程只能排队等已有连接释放，压测效果会大打折扣。

QPS 的计算，我在代码里做了一个简化估算：总请求数除以每请求耗时的平均值再除以 1000（换算成秒）。严格来说，更准确的 QPS 应该是“测试期间内完成的请求数除以测试总时长”，也就是用墙钟时间来算。你可以在 run_load 函数里记录一下开始和结束时间，再用 total_requests / (end - start) 得到精确值。这段代码里的估算方法在延迟分布比较均匀时误差不大，但如果请求耗时波动很大，建议改用墙钟时间。

3.4 一次完整的实测记录

我用这个脚本对本机一个简单的 Flask 服务做了一次压测。目标接口的逻辑就是读一次数据库缓存然后返回 JSON，平均耗时大概 10ms。测试场景是并发 200，总请求 20000，结果如下：

压测目标: http://127.0.0.1:5000/api/demo, 并发: 200, 总请求: 20000 并发数: 200 请求总数: 20000, 错误数: 0 QPS(估算): 20000.00 平均延迟: 10.25 ms P50: 9.80 ms P95: 15.42 ms P99: 24.36 ms 状态码分布: {200: 20000}

从数据看，QPS 大约 20000，和公式 C = QPS × L 是吻合的（200 并发、10ms 延迟）。P95 和 P99 明显高于平均值，说明存在小部分请求因为锁竞争或 GC 停顿导致延迟变长，需要对那一小部分做进一步分析。对于演示来说，整套流程跑通了，数据也具备参考价值。

4. 常见问题与排查技巧实录

写压测工具的思路不难，难的是真正跑起来之后遇到各种怪问题。这一节我把实际压测中经常遇到的现象、原因和排查路径整理成一份速查表，并且针对几个典型问题展开说说。

4.1 文件描述符与端口耗尽问题

这个问题属于压测客户端的经典问题。默认的 1024 文件描述符上限，对小型脚本够用，但对压测来说完全不够。有一次我在压测时忘了调 ulimit，并发 500 都没到，程序就抛了 OSError: [Errno 24] Too many open files。当时排查花了一点时间，因为第一反应是代码写错了，仔细检查才发现是系统限制。

解决方法是动态调整和永久配置结合。当前会话可以用 ulimit -n 65535 临时解决。如果你要用 systemd 运行压测任务，那要在 service 文件里加 LimitNOFILE=65535；如果你用 Docker，要加上 --ulimit nofile=65535:65535。总而言之，容器环境比裸机多一层限制，别漏了。

端口耗尽的问题在压测外部服务时更常见。单个源 IP 发起大量连接，本地端口池只有约 28000 个可用的临时端口（默认范围 32768-60999），如果连接不复用，高并发下很容易把端口池用尽。解决思路有两个方向：一是压测客户端尽量复用 HTTP 长连接，让同一连接承载多个请求，这样端口占用少很多；二是如果必须用短连接，就要扩大临时端口范围。但临时端口范围最多也就 64511 个上限，再高就需要多源 IP 了。

4.2 超时设置与请求汇总阶段的阻塞

压测过程中，有时候你会发现前几秒 QPS 很猛，后来越来越慢，最后结果惨不忍睹。这种情况很多不是目标服务的锅，而是压测客户端自身出了问题。常见的一种是超时设置过长，加上并发很高，导致很多请求卡在等待响应上。一旦目标服务某个瞬间处理不过来，响应变慢，未完成的请求越积越多，客户端内存跟着涨，事件循环要处理的定时器也变多，整个压测客户端的性能就开始劣化。

我的经验是：先小并发跑一分钟，观察正常的响应时间分布，把超时设成 P99 的两到三倍。如果目标服务弱到连两三倍的 P99 都等不起，那这个接口也谈不上什么性能。压测的目的是发现问题，不是把客户端自己压垮。

另外还有一种特殊情况，就是压测结束前的“收尾阻塞”。当你用 asyncio.gather 等待所有协程完成时，如果某个协程里有一个请求因为网络状况迟迟不返回，即使你设置了超时，也可能要等到超时那一刻才真正结束。所以整体压测时长会比你预想的长不少。解决方案是宁可让每次请求超时短一点，也不要让整个压测任务无限拖下去。

4.3 结果数据分析的经验：先看错误再看延迟

拿到压测结果之后，我的分析顺序永远是：先看错误率，再看状态码分布，最后才看延迟分位数。如果错误率很高，那延迟数据基本没有意义，因为服务已经处于异常状态了。先确认接口在压力下是否“正确地工作”，再谈“多快”的问题，这个顺序不能乱。

在 colibri 这类极简工具的帮助下，你更容易理解这个道理，因为它的输出非常朴素，只是告诉你每个请求的返回码和耗时。这种朴素恰恰是优势：没有花哨的图表，逼着你看原始数据本身。很多人压测拿到一份漂亮的报告数据就完事了，很少回头去看那些慢请求发生在什么时间窗口、是什么状态码、是不是集中在某个并发高峰段。这些细节才是定位瓶颈的关键。有一次我排查一个性能问题，发现所有慢请求都集中在压测开始的 30 秒到 60 秒之间，和服务端某个定时任务重合，这就是单纯看平均延迟根本发现不了的。

4.4 压测外部服务时一定要做的几件事

如果你压测的不是本机服务，而是跨网络的外部接口，有几件事必须提前做。第一，用 ping 和 curl 先确认网络延迟和连通性，判断是网络瓶颈还是服务处理瓶颈。第二，确认目标服务是否有防火墙或网关层面的限流策略，否则你压测到的只是入口网关的极限，而不是业务服务的极限。第三，压测前提前告知相关团队，避免把正在联调或生产的服务压出问题。这些看起来是常识，但实际执行时总有人漏掉，我见过不止一次因为压测把线上服务打挂的事故。

还有一点容易被忽略，就是要预留测试数据的清理方案。压测会产生大量真实请求，如果你的接口有写库逻辑，数据库里会被灌入成批的测试数据。压测前就想好怎么识别并清理这些数据，不然事后清理的工作量也够喝一壶的。

5. 我的一点实践心得和后续扩展思路

colibri 这个项目让我重新思考了一个问题：做工具到底要加多少功能才够？在它身上，答案是“够用就行”。一个文件、几百行代码，就把压测最核心的事情讲清楚了。作为参考学习的项目，它的价值不在功能丰富，而在于帮你建立对异步 I/O 和性能测试底层逻辑的直观理解。有了这个基础，再去用 wrk、JMeter 这些功能更全的工具时，你大概能猜出它们那些复杂配置背后的设计缘由了。

从扩展的角度看，这类极简压测脚本后续能往几个方向延伸。一是增加持续压测模式，让压测运行固定时长而不是固定请求数，这样更容易观察服务在长时间高负载下的稳定性。二是接入更丰富的指标输出，比如把数据写到 Prometheus 或者日志文件，结合 Grafana 做实时监控大盘。三是增加并发数阶梯调节，让脚本能在运行过程中自动按预设梯度提升并发，省去人工反复启动压测的麻烦。这些扩展本身的代码量都不大，但带来的分析能力提升是实打实的。

最后分享一个调优中的小技巧：压测客户端所在的机器，最好独占，不要在上面跑其他吃资源的任务。我试过在压测客户端上开着一堆浏览器和服务，结果压测数据的波动明显变大。压测本身追求的是控制变量，客户端环境越干净，数据越能真实反映目标服务的性能水平。多准备几台干净的压测机，比在一台机器上无限调参要靠谱得多。