前言某个接口变慢了是运维反馈里最含糊的一句话。它可能意味着 PHP 代码里有个慢查询也可能意味着 PHP-FPM 的进程池太小导致请求排队还可能意味着这个接口调用了一个超时时间设成默认值的第三方服务而对方今天恰好抖动了一下。这三种原因的解决方向完全不同猜错方向的优化就是白干。PHP 8.2 本身在性能上并没有什么新东西JIT 是 8.0 引入的纤维是 8.1 引入的所以定位性能瓶颈依靠的不是语言版本而是一套从外到内的分层测量方法先确认时间花在哪一层再进到那一层里继续切分直到找出占比最高的那一段。更常见的是反过来直接打开 Xdebug 看火焰图。这有两个问题——Xdebug 的插桩开销极大结论严重失真而且它只看得到 PHP 代码内部的时间看不出 PHP-FPM 排队、DNS 解析、数据库等待这些真正的大头。本文按先分层、后深入的顺序讲第一部分是分层测量手段第二部分是 PHP 层最常见的四个瓶颈第三部分是数据库和外部依赖最后列坑。一、先分层别急着优化1.1 时间都花在哪一层一个 HTTP 请求的耗时可以拆成下面几段从客户端视角先确认是哪一段在涨层次观测手段典型元凶DNS 与 TCP/TLScurl -w的时序变量DNS 解析慢、TLS 握手往返Web 服务器队列Nginx access log 的$request_time与$upstream_response_time差值连接数打满、静态资源阻塞PHP-FPM 排队pm.status_path的listen queue与max children reached进程池过小、请求被串行排队PHP 执行应用内 span 采集、FPMslowlog的 PHP 调用栈慢函数、大对象序列化、正则回溯数据库慢查询日志、EXPLAIN缺索引、N1 查询外部服务curl超时设置、调用日志未设超时导致串行等待第一步用 curl 的-w参数把时序拆开这个动作不需要改任何代码curl -s -o /dev/null -w \ dns%{time_namelookup} connect%{time_connect} tls%{time_appconnect} ttfb%{time_starttransfer} total%{time_total}\n \ http://127.0.0.1:8000/api/orders看几个关键差值time_starttransfer - time_appconnect约等于服务端处理时间含 FPM 排队time_connect - time_namelookup是 TCP 建连耗时这一段不正常问题就跟 PHP 无关。1.2 在应用内埋一套轻量 spancurl 只能给出总时长具体是哪段 PHP 逻辑慢需要在代码里打点。用hrtime(true)做单调时钟它不受系统时间调整影响microtime(true)会外面套一层极薄的 span 收集器?php // profiler.php —— 需要 PHP 7.4 declare(strict_types1); final class Profiler { /** var arraystring, float */ private static array $spans []; /** var listarray{0: string, 1: int} */ private static array $stack []; private static int $start 0; public static function start(): void { self::$spans []; self::$stack []; self::$start hrtime(true); } public static function begin(string $name): void { self::$stack[] [$name, hrtime(true)]; } public static function end(): void { $frame array_pop(self::$stack); if ($frame null) { return; } [$name, $t0] $frame; // 同名 span 累加适合统计循环里的总耗时 self::$spans[$name] (self::$spans[$name] ?? 0.0) (hrtime(true) - $t0) / 1_000_000; } public static function wrap(string $name, callable $fn): mixed { self::begin($name); try { return $fn(); } finally { self::end(); } } public static function report(): array { $total (hrtime(true) - self::$start) / 1_000_000; $rows []; foreach (self::$spans as $name $ms) { $rows[] [ span $name, ms round($ms, 2), percent $total 0.0 ? round($ms / $total * 100, 1) : 0.0, ]; } usort($rows, static fn(array $a, array $b): int $b[ms] $a[ms]); return [total_ms round($total, 2), spans $rows]; } }用wrap()包住可疑的逻辑段代码侵入性很低比如Profiler::wrap(db.users, fn() $repo-findAll())。report()返回按耗时倒序排列的数组排第一的那段就是优化目标——没有这份分解任何优化都是猜。1.3 生产环境取证PHP-FPM 的 slowlog不改编代码也能拿到慢请求的 PHP 调用栈靠的是 PHP-FPM 自带的 slowlog。它会在请求超过阈值时把当前的 PHP 函数调用栈完整写进日志这是排查线上偶发慢请求性价比最高的手段; /etc/php/8.2/fpm/pool.d/www.conf request_slowlog_timeout 3s slowlog /var/log/php-fpm/slow.log request_terminate_timeout 30s pm dynamic pm.max_children 32 pm.start_servers 8 pm.min_spare_servers 4 pm.max_spare_servers 12 pm.max_requests 500同时打开 FPM 的状态页观察是否在排队; 同一个 pool 配置文件 pm.status_path /fpm-statuslocation /fpm-status { allow 127.0.0.1; deny all; include fastcgi_params; fastcgi_pass unix:/run/php/php8.2-fpm.sock; }curl -s http://127.0.0.1/fpm-status?full重点看这四个字段listen queue等待被处理的请求数、max listen queue历史峰值、max children reached进程池耗尽的次数、slow requests触发 slowlog 的次数。只要max children reached大于 0 或者listen queue长期非零说明请求在排队等进程此时再怎么优化 PHP 代码也没用该调的是进程池大小或者单请求的耗时。二、PHP 层最常见的四个瓶颈2.1 opcache 配置不当opcache 把编译后的字节码缓存在共享内存里省掉每个请求的编译开销。它在 PHP 8.2 里通常默认开启但默认参数是按小项目配的文件数量一多就会失效。用opcache_get_status()直接读运行状态?php // opcache-check.php —— 需要 PHP 7.4 declare(strict_types1); header(Content-Type: text/plain; charsetutf-8); $status opcache_get_status(false); if ($status false) { exit(opcache 未启用或不可用\n); } $stats $status[opcache_statistics]; $memory $status[memory_usage]; printf(opcache 启用 : %s\n, $status[opcache_enabled] ? 是 : 否); printf(已缓存脚本数 : %d\n, $stats[num_cached_scripts]); printf(命中 / 未命中 : %d / %d\n, $stats[hits], $stats[misses]); printf(哈希表容量 : %d\n, $stats[max_cached_keys]); printf(哈希表重启次数 : %d\n, $stats[hash_restarts]); printf(内存耗尽重启次数 : %d\n, $stats[oom_restarts]); printf(手动重启次数 : %d\n, $stats[manual_restarts]); printf(剩余可用内存 : %.1f MB\n, $memory[free_memory] / 1048576); printf(浪费的内存 : %.1f MB (%.2f%%)\n, $memory[wasted_memory] / 1048576, $memory[current_wasted_percentage]);判读方式很直接观察值含义调整方向hash_restarts持续增长缓存脚本数超过max_cached_keys哈希表反复重建调大opcache.max_accelerated_filesoom_restarts大于 0共享内存不够缓存被整体清空调大opcache.memory_consumptioncurrent_wasted_percentage偏高旧脚本占着空间等回收发布后执行opcache_reset()或重启 FPMmisses比例高缓存在频繁失效检查是否被反复重启对应的配置opcache.enable 1 opcache.memory_consumption 192 opcache.max_accelerated_files 20000 opcache.interned_strings_buffer 32 opcache.validate_timestamps 0 opcache.save_comments 1validate_timestamps 0表示不再检查源文件是否被修改这是生产环境的推荐值——代价是每次发布代码之后必须主动让 FPM 重新加载否则新代码不会生效sudo systemctl reload php8.2-fpmsave_comments保持为 1因为注解attributes和大量框架依赖注释解析。2.2 会话文件锁把并发请求串行化这是最容易被误判成服务器性能不行的一个原因。PHP 默认的会话处理器把 session 存成文件session_start()会对该文件加排他锁直到脚本结束才释放。同一用户的多个并发请求因此被强行串行化前端同时发三个 AJAX总耗时等于三者之和。?php // session-lock.php —— PHP 7.4 declare(strict_types1); session_start(); // 只读取和写入必要的会话数据 $_SESSION[last_seen] time(); $userId $_SESSION[user_id] ?? null; // 关键数据写完了就立刻关闭会话释放文件锁 session_write_close(); // 后面无论多慢的逻辑都不会再阻塞同一用户的其它请求 usleep(80000); // 模拟一段耗时逻辑 $result [user $userId, orders 12]; header(Content-Type: application/json; charsetutf-8); echo json_encode($result, JSON_UNESCAPED_UNICODE), PHP_EOL;原则很简单会话数据只在请求最开始读一次、在最后写一次中间任何时候都不该持有锁。如果业务上确实需要在整个请求期间保持会话一致比如购物车可以把会话存储换成 Redis并用支持并发读的实现或者显式关闭锁。2.3 外部依赖没有设置超时这类问题的表现是平时很快偶尔整个接口卡住十几秒。原因是file_get_contents()请求远程地址时使用的默认 socket 超时由default_socket_timeout决定默认值可能长达 60 秒一旦对方不响应当前请求就挂在那里等把所有可用的 FPM 进程一起拖死。?php // http-with-timeout.php —— PHP 7.4 declare(strict_types1); // 带严格超时的 HTTP GET失败返回 null function fetchJson(string $url, int $connectMs 500, int $totalMs 1500): ?array { $ch curl_init($url); if ($ch false) { return null; } curl_setopt_array($ch, [ CURLOPT_RETURNTRANSFER true, CURLOPT_CONNECTTIMEOUT_MS $connectMs, CURLOPT_TIMEOUT_MS $totalMs, CURLOPT_FOLLOWLOCATION false, CURLOPT_HTTPHEADER [Accept: application/json], ]); $body curl_exec($ch); $errno curl_errno($ch); curl_close($ch); if ($errno ! 0 || $body false) { return null; } $decoded json_decode($body, true); return is_array($decoded) ? $decoded : null; } $data fetchJson(http://127.0.0.1:9/nothing); // 指向一个不会响应的端口 var_dump($data); echo 失败后立刻返回没有长时间阻塞, PHP_EOL;CURLOPT_CONNECTTIMEOUT_MS管建连阶段CURLOPT_TIMEOUT_MS管整个请求两个都要设而且必须是毫秒级的短值。降级逻辑也要有——外部服务挂了不该让整个接口跟着挂。如果一次请求要调多个互不依赖的外部接口改用curl_multi_*系列并发发出总耗时取决于最慢的那个而不是所有耗时之和。2.4 循环里查询数据库N1?php // n-plus-one.php —— PHP 7.4 declare(strict_types1); $pdo new PDO(sqlite::memory:); $pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $pdo-exec(CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)); $pdo-exec(CREATE TABLE orders (id INTEGER PRIMARY KEY, user_id INTEGER, amount INTEGER)); for ($i 1; $i 50; $i) { $pdo-prepare(INSERT INTO users (id, name) VALUES (?, ?))-execute([$i, user{$i}]); $pdo-prepare(INSERT INTO orders (id, user_id, amount) VALUES (?, ?, ?)) -execute([$i, $i, $i * 10]); } $users $pdo-query(SELECT id, name FROM users)-fetchAll(PDO::FETCH_ASSOC); // ❌ N150 个用户就是 50 次查询 $timings []; $t0 hrtime(true); $bad []; foreach ($users as $user) { $stmt $pdo-prepare(SELECT COUNT(*) FROM orders WHERE user_id ?); $stmt-execute([$user[id]]); $bad[$user[id]] (int) $stmt-fetchColumn(); } $timings[N1] (hrtime(true) - $t0) / 1_000_000; // ✅ 一次 IN 查询拿完 $t0 hrtime(true); $ids array_column($users, id); $placeholders implode(,, array_fill(0, count($ids), ?)); $stmt $pdo-prepare( SELECT user_id, COUNT(*) AS cnt FROM orders WHERE user_id IN ($placeholders) GROUP BY user_id ); $stmt-execute($ids); $good []; foreach ($stmt-fetchAll(PDO::FETCH_ASSOC) as $row) { $good[(int) $row[user_id]] (int) $row[cnt]; } foreach ($ids as $id) { $good[$id] $good[$id] ?? 0; } $timings[IN 批量] (hrtime(true) - $t0) / 1_000_000; var_dump($bad $good); foreach ($timings as $name $ms) { printf(%-8s %.3f ms\n, $name, $ms); }两种写法结果完全一致但查询次数从 51 次降到 2 次。真正的收益不在单次查询有多快而在网络往返次数的量级差异——无论数据库是在本机还是跨网络每多一次往返就多一次固定成本外加一次排队风险。上面这段代码可以在本地跑用 SQLite 内存库得出的数字只反映相对关系不代表任何真实生产环境的性能。常见坑点❌ 只盯着 PHP 代码看不查 PHP-FPM 的状态页 ✅ 先看max children reached和listen queue只要它们非零瓶颈就在进程排队而不是代码逻辑优化代码毫无意义❌ 在session_start()之后才执行所有耗时逻辑 ✅ 会话文件锁会把同一用户的并发请求串行化读写完会话就立刻session_write_close()释放锁❌ 用file_get_contents()调用第三方接口且不设超时 ✅ 默认超时可能长达 60 秒对方一抖动就把当前请求和整个进程池一起拖住改用 curl 并显式设置CURLOPT_TIMEOUT_MS❌ 用平均响应时间评估接口性能 ✅ 平均值会把长尾藏起来卡顿往往只体现在 P95、P99 上打点时要保留分位数而不是只留均值❌ 把opcache.max_accelerated_files留在默认值不管 ✅ 大项目的文件数轻易超过默认容量会触发哈希表重建hash_restarts增长导致缓存频繁失效按项目实际文件数量调大❌ 生产环境设了opcache.validate_timestamps 0却忘了发布流程 ✅ 关掉时间戳校验后新代码不会自动生效发布脚本必须包含systemctl reload php8.2-fpm❌ 在循环里逐条查询数据库 ✅ N1 的成本主要是往返次数量级改成一次IN查询加GROUP BY查询次数可以从几十次降到一两次总结观测层工具 / 手段判读要点客户端时序curl -w的time_namelookup/time_connect/time_starttransfer区分网络耗时与服务端耗时FPM 排队pm.status_path状态页listen queue、max children reached非零就是排队PHP 调用栈FPMrequest_slowlog_timeoutslowlog超时请求的函数调用栈无需改代码应用内分段hrtime(true) span 收集器按占比排序只优化占比最高的段opcacheopcache_get_status()hash_restarts、oom_restarts、wasted_memory数据库慢查询日志、EXPLAIN ANALYZE缺索引、返回行数估算偏差外部服务CURLOPT_CONNECTTIMEOUT_MS、CURLOPT_TIMEOUT_MS必须有毫秒级超时和降级逻辑性能定位的核心原则只有一条先测量再优化而且只优化占比最高的那一段。分层测量能在动手前排除掉大半错误方向——curl 的时序分解告诉你问题在网络还是服务端FPM 状态页告诉你瓶颈在排队还是代码应用内的 span 告诉你该改哪个函数。跳过测量直接改代码就是猜。