FrankenPHP怎么测试登录接口的并发性能-php教程-PHP中文网

不能用ab或jmeter默认配置压登录接口，因ab不支持cookie管理和重定向，jmeter默认不维护会话上下文；若未配置http cookie manager和json extractor提取token，90%请求将返回302或401，导致qps虚高、结果无效。

frankenphp怎么测试登录接口的并发性能

直接用 wrk 压测登录接口，但必须带登录态 Cookie 或 Token，否则测的只是“未登录跳转”，不是真实并发逻辑。

为什么不能用 ab 或 JMeter 默认配置压登录接口

ab 不支持自动处理重定向和 Cookie 管理；JMeter 默认不维护会话上下文，若没配 HTTP Cookie Manager 和 JSON Extractor 提取 token，发出去的全是无效凭据。结果是 90% 请求返回 302 或 401，QPS 虚高、毫无参考价值。

登录接口本质是状态变更 + 会话建立，必须模拟「先 POST 凭据 → 拿到 Set-Cookie 或 JWT → 后续请求携带」这一链路
FrankenPHP 的 worker 模式下，session_start() 或 JWT 验证逻辑若依赖未复用的资源（如每次 new PDO），并发一上来就会卡在连接池或文件锁上
不带凭证的压测，FrankenPHP 可能直接走 Caddy 静态路由或未认证中间件，根本不会进 PHP 层

用 wrk + Lua 脚本实现带登录态的并发压测

wrk 支持自定义 Lua 脚本，在每个连接初始化时执行登录流程，然后复用该连接持续发送带凭证的请求。这是目前对 FrankenPHP 最轻量、最可控的方式。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

写一个 login.lua，内容类似：

init = function(args)
  -- 首次请求登录，获取 cookie
  local r = wrk.request("POST /login HTTP/1.1\r\nHost: localhost:8000\r\nContent-Type: application/json\r\n\r\n{\"email\":\"test@example.com\",\"password\":\"pass\"}")
  local _, _, headers, body = wrk.response(r)
  wrk.cookies = headers["Set-Cookie"] or ""
end
<p>request = function()
-- 后续所有请求都带上 cookie
return wrk.request("GET /api/profile HTTP/1.1\r\nHost: localhost:8000\r\nCookie: " .. wrk.cookies .. "\r\n\r\n")
end</p>

执行命令：wrk -t4 -c100 -d30s -s login.lua http://localhost:8000/api/profile
关键点：-t4 是线程数，-c100 表示维持 100 个长连接，每个连接只登录一次，后续全复用凭证；若用 -c100 -d30s 发 100 个独立登录请求，就变成测「账号密码校验」而非「登录后接口并发」
注意路径必须是登录后才能访问的接口（如 /api/profile），别压 /login 本身——那测的是鉴权逻辑，不是业务并发

FrankenPHP 下登录接口特有的瓶颈点

和传统 FPM 不同，FrankenPHP 的 worker 进程常驻，session 或 JWT 验证中间件若用了静态变量缓存、或没清空上一次请求的 $_SESSION，会导致凭证污染、500 或静默返回旧数据。

检查 Laravel/Symfony 中是否启用了 session.auto_start —— FrankenPHP 不支持，必须显式调用 session_start()，且确保每次请求后调用 session_write_close()
若用数据库查用户（非 Redis 缓存），确认 PDO 连接已设 PDO::ATTR_PERSISTENT => true，否则每请求新建连接，max_connections 很快打满
OPcache 必须启用且排除 login.php 类入口文件（防止登录失败后缓存了错误响应），可通过 opcache.blacklist_filename 配置
用 curl -w 'time_starttransfer=%{time_starttransfer}\n' 单独测一次登录请求，如果 time_starttransfer > 1s 但 CPU 很低，大概率卡在 DNS 解析（gethostbyname）或 SMTP 登录回调（比如登录成功发邮件）这类同步阻塞操作