PHP慢请求怎么定位

本文目录导读：

1. 常见原因分类
2. 快速定位三板斧
3. 分层定位流程
4. 进阶分析工具
5. 实战案例分析
6. 核心建议

定位PHP慢请求是一个系统性的排查过程，需要从应用层到基础设施层逐层深入,以下是完整的定位方法论和实战工具清单：

---

常见原因分类

类别	典型原因
代码逻辑	死循环、N+1查询、大数组遍历
数据库	慢SQL、锁等待、连接数耗尽
外部依赖	第三方API超时、Redis阻塞
资源配置	PHP-FPM进程数不足、内存限制
环境问题	CPU飙高、磁盘IO阻塞、Swap占用

---

快速定位三板斧

全局监控（先看趋势）

# 查看PHP-FPM实时状态
curl http://localhost/phpfpm_status
# 输出示例：
pool:                 www
process manager:      dynamic
start time:           10/Oct/2023:14:30:00 +0800
start since:          3600
accepted conn:        12500
listen queue:         12          # 明显堆积，说明请求处理不过来
max listen queue:     30
listen queue len:     128
idle processes:       2           # 空闲进程太少
active processes:     48          # 活动进程接近max_children
total processes:      50
max active processes: 50          # 已触顶
max children reached: 5           # 已触发过最大子进程
# 启用phpfpm_status需在php-fpm.conf配置
pm.status_path = /phpfpm_status

实时抓取慢请求（最有效）

# 方法1：启用PHP-FPM慢日志
# php-fpm.conf 配置：
request_slowlog_timeout = 2s
slowlog = /var/log/php-fpm/slow.log
request_terminate_timeout = 30s
# 查看慢日志（会记录调用栈）
cat /var/log/php-fpm/slow.log
# 方法2：使用strace跟踪（实时定位阻塞点）
strace -p $(pgrep php-fpm | head -1) -T -f -o /tmp/strace.log

代码埋点（长期观察）

// 在入口文件（index.php）加入
$GLOBALS['_start_time'] = microtime(true);
// 在目标接口/PHP文件结束前
$elapsed = microtime(true) - $GLOBALS['_start_time'];
if ($elapsed > 3) {  // 超过3秒记录
    error_log(json_encode([
        'uri' => $_SERVER['REQUEST_URI'],
        'time' => $elapsed,
        'trace' => (new \Exception())->getTraceAsString()
    ]), 3, '/tmp/slow_requests.log');
}

---

分层定位流程

Step 1：确认瓶颈在PHP还是外部（关键步骤）

# 查看请求处理时间分布
# 临时在入口文件加：
$start = microtime(true);
// 在程序结束前：
$end = microtime(true);
$php_exec = $end - $start;  // PHP自身执行时间
// 如果PHP自身执行时间很短，说明时间耗在外部依赖
# 使用curl模拟请求并计时
curl -w "total: %{time_total}s, connect: %{time_connect}s, starttransfer: %{time_starttransfer}s\n" -o /dev/null your-url

Step 2：数据库排查（最常出问题）

-- 查看当前执行中的SQL
SHOW FULL PROCESSLIST;
-- 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;
SET GLOBAL slow_query_log_file = '/tmp/mysql_slow.log';
-- 分析慢SQL
mysqldumpslow -s t -t 10 /tmp/mysql_slow.log
-- 检查锁等待
SELECT * FROM information_schema.INNODB_TRX\G;
SELECT * FROM sys.innodb_lock_waits\G;

Step 3：第三方服务排查（Redis/API等）

# 查看Redis慢查询
redis-cli slowlog get 10
# 监控外部API调用
strace -f -e trace=network -p PID 2>&1 | grep connect
# 常见方案：连接池 + 超时限制 + 熔断
// 设置合理超时
$options = [
    'timeout' => 2.0,
    'connect_timeout' => 1.0
];
$client = new GuzzleHttp\Client($options);

---

进阶分析工具

Xdebug Profiling（定位代码级瓶颈）

[xdebug]
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=/tmp
xdebug.profiler_output_name=cachegrind.out.%p
# 使用工具分析
# 方式1：Webgrind
php -S localhost:8080 /path/webgrind
# 方式2：命令行
php /path/vendor/bin/phpcpd /tmp/cachegrind.out.*
# 方式3：生成火焰图
php /path/vendor/bin/xhprof some_script.php

HHVM/Xdebug图形化

# 使用黑火（Blackfire）或 Tideways 等APM工具
curl -OL https://blackfire.io/install.sh
bash install.sh

系统级分析

# 查看CPU/内存
top -bn1 | grep php-fpm | sort -k9 -r | head -20
# 查看进程是否阻塞在IO
iotop -d 2
perf top -p $(pgrep php-fpm | head -1)
# 检查PHP-FPM进程状态
ps aux | grep php-fpm | grep -v grep | awk '{print $2, $3, $4, $11, $12}'

---

实战案例分析

案例1：数据库锁等待

症状：响应时间从30ms增加到5s
定位：
1. 慢日志显示大量 `Lock wait timeout exceeded`
2. SHOW PROCESSLIST 显示大量 `Waiting for table metadata lock`
解决：
- 优化事务大小，缩短持锁时间
- 检查是否有未提交的ALTER TABLE

案例2：N+1查询

// 罪魁祸首代码
$users = User::all();
foreach ($users as $user) {
    $posts = $user->posts;  // 每行执行一次SQL
}
// 定位方法：开启SQL日志
DB::enableQueryLog();
// ... 执行完
$queries = DB::getQueryLog();
if (count($queries) > 50) {  // 发现500次查询！
    error_log("N+1 detected!");
}

案例3：外部API慢

症状：特定接口总是慢3-5秒
定位：strace显示 connect() 系统调用耗时3.2秒
解决：
- 增加连接超时
- 使用异步调用
- 加缓存或降级方案

---

核心建议

阶段	工具/技术	优先级
预防	APM监控（NewRelic/Blackfire）	中
发现	日志 + 慢请求告警	高
定位	strace + Xdebug	高
解决	缓存、队列、异步	中

最佳实践：

1. 永远开启PHP-FPM的slowlog，即使生产环境设置request_slowlog_timeout = 5s
2. 数据库慢查询日志必须开启，阈值设为2秒
3. 定期分析慢日志，建立基准值，有异常自动告警

通过以上方法，90%以上的慢请求都能在5分钟内定位到根因，如果问题依然难以排查，可以考虑使用ELK集中日志分析,或在风控允许的情况下使用APM工具进行深度分布式追踪。