JMeter压测前必须调对线程数、Ramp-up时间、循环次数三个核心参数：线程数为虚拟用户数，Ramp-up为线程启动窗口（设0即瞬时并发），循环次数决定每个线程请求轮次，总请求数=线程数×循环次数。
别用 PHP 脚本自己写循环压测 API——你测的不是接口，是 PHP 自己的阻塞调度和内存管理。真实瓶颈在 FPM 队列、MySQL 连接池或 Nginx 限流，这些必须靠外部工具触发并发才能暴露。
JMeter 压测前必须调对的三个核心参数
JMeter 不是点开就跑的图形界面玩具，错配线程组参数会导致结果完全失真。
-
Number of Threads (users)：虚拟用户数，不是“并发请求数”。每个线程默认串行发请求，除非你加了“Constant Throughput Timer”或设置“Ramp-up period = 0” -
Ramp-up period (seconds)：启动所有线程的时间窗口。设成 0 表示瞬间拉满；设成 60 表示 1 分钟内匀速启完。线上突发流量更接近 0，灰度验证建议从 30 秒起步 -
Loop Count：每个线程执行采样器的次数。总请求数 = 线程数 × 循环次数。别只改线程数而忽略它——比如 100 线程 × 10 次 = 1000 请求，和 50 线程 × 20 次效果不同，后者对服务端压力更持续
HTTP 请求采样器里最容易漏掉的关键配置
PHP 接口常依赖 Cookie、Header 或 JSON Body，JMeter 默认不带这些，一压就 401 或 500。
- POST 请求必须手动选中
Use multipart/form-data for POST或Parameters标签页填键值对；传 JSON 就切到Body Data标签页，粘贴完整 JSON 字符串，并在Content-TypeHeader 里加application/json - 登录态维持靠
HTTP Cookie Manager元件——它自动提取 Set-Cookie 并回传，没加这个，第二步请求必然失败 - 若接口返回
Content-Encoding: gzip，JMeter 默认不解压，响应体显示乱码。需在HTTP Request Defaults里勾选Retrieve All Embedded Resources并启用Use KeepAlive，或加一个JSR223 PostProcessor手动解压
看懂 JMeter 报告里真正要盯的三行数字
别只扫一眼 “Average Response Time”，那只是幻觉。关键指标藏在 Aggregate Report 和 View Results in Table 的组合里。
-
90% Line和95% Line：比平均值更有意义。如果平均 200ms，但 p95 是 1200ms，说明 5% 请求严重拖慢，大概率是数据库慢查询或 Redis 连接超时 -
Error %：注意错误类型。Non HTTP response code: java.net.SocketTimeoutException是客户端等不到响应，可能后端卡死；502/504多是 Nginx 到 PHP-FPM 的超时，该调fastcgi_read_timeout；500集中出现则查 PHP 错误日志 -
Received KB/sec：如果吞吐量上不去但 CPU 很低，可能是输出被 gzip 压缩后带宽打满，或响应体过大（如未分页返回全量数据）
压测不是调完参数就完事——wrk 发现延时飙升时，得立刻去看 pm.queue_length；JMeter 报错率突增，第一反应不是改脚本，而是 tail -f /var/log/php-fpm/www-slow.log。工具只负责捅出问题，根因永远在日志、监控和配置的交叉点上。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
