autocannon转Locust性能测试代码后无法达到3000 req/s问题咨询

一、代码层面优化 #

• 移除所有冗余日志：删除_log方法及所有print调用，磁盘IO和标准输出是性能瓶颈的核心来源，压测场景下禁止打印请求参数、响应内容等调试信息。
• 移除不必要的逻辑校验：删除响应内容正则匹配判断，直接使用try...except捕获解析JSON即可，针对本次测试的固定PUT接口可直接调用resp.json()，省去正则匹配开销。
• 全局复用登录Token：不要在每个用户的on_start方法中单独调用登录接口，在模块初始化阶段统一调用一次登录接口获取全局Token，所有请求复用该Token，减少无效登录请求开销。
• 简化封装层级：删除不必要的SequentialTaskSet封装，直接将任务逻辑写在FastHttpUser子类中，Locust官方已不推荐优先使用TaskSet，额外的封装会增加调用开销。
• 关闭SSL证书校验：在FastHttpUser类中添加insecure = True属性，跳过本地自签HTTPS证书校验逻辑，减少加密校验开销。

示例优化后核心代码：

from locust import FastHttpUser, task
import requests
import urllib3
# 关闭HTTPS警告
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

# 全局预取认证Token
AUTH_HEADER = None
def init_token():
    global AUTH_HEADER
    resp = requests.get(
        "https://localhost:5443/api/v1/login",
        auth=("admin", "admin"),
        verify=False
    )
    AUTH_HEADER = f"Bearer {resp.json()['token']}"

init_token()

class PerformanceTestUser(FastHttpUser):
    insecure = True
    default_headers = {
        "Content-Type": "application/json",
        "Authorization": AUTH_HEADER
    }

    @task
    def put_applications(self):
        self.client.put(
            "/applications",
            json={"name": "test"}
        )

二、运行参数优化 #

• 调整并发用户数：autocannon的30连接是异步非阻塞模型，Locust的用户数对应并发请求数，若接口响应时间高于10ms，需适当上调用户数，可先尝试设置-u 100逐步压测到目标QPS。
• 绑定CPU核心：和autocannon一样使用taskset绑定进程到指定CPU核心，避免CPU调度开销，单实例运行命令参考：

taskset -c 8-15 locust --locustfile performance.py --host https://localhost:5443/api/v1 --headless -u 100 -i 100000 --skip-log-setup

• 分布式运行优化：每个worker进程单独绑定一个CPU核心，master节点仅负责调度不要运行业务逻辑，8 worker启动示例：

# master节点
taskset -c 15 locust --locustfile performance.py --host https://localhost:5443/api/v1 --headless -u 200 -i 100000 --master --expect-workers=8 --skip-log-setup
# 启动8个worker分别绑定8-14核心
for i in {8..14}; do taskset -c $i locust --locustfile performance.py --worker --master-host=127.0.0.1 --skip-log-setup & done

• 关闭多余日志：运行时添加--skip-log-setup参数，禁用Locust默认的日志输出，进一步减少IO开销。

三、额外注意事项 #

• 避免在压测机器上运行其他占用CPU/IO的进程，保证资源全部用于压测。
• 确认服务端性能没有达到瓶颈，优先排除服务端本身无法承载3000 req/s的可能性。
• 可使用--csv参数导出压测结果，不要实时打印监控数据，减少前台输出开销。

内容的提问来源于stack exchange，提问作者Mike