PHP-FPM 慢日志分析与性能优化实录

PHP-FPM 慢日志分析与性能优化实录：从发现瓶颈到性能提升的完整指南

作为一名长期与 PHP 应用打交道的开发者，我最近在项目中遇到了一个棘手的性能问题：某个 API 接口响应时间偶尔会飙升至数秒。经过排查，最终通过 PHP-FPM 慢日志定位并解决了问题。今天我就来分享这段实战经历，希望能帮助遇到类似问题的你。

为什么要启用 PHP-FPM 慢日志

在开始配置之前，我们先理解慢日志的价值。PHP-FPM 慢日志类似于 MySQL 的慢查询日志，它会记录执行时间超过指定阈值的 PHP 脚本。当应用出现性能瓶颈时，这往往是我们排查问题的第一手资料。

记得有一次，我们的应用在高峰期频繁超时，但错误日志中没有任何明显异常。正是启用了慢日志后，才发现是某个第三方 API 调用在某些情况下响应极慢，拖累了整个请求。

配置 PHP-FPM 慢日志

配置过程其实很简单，主要涉及修改 php-fpm.conf 或 pool 配置文件。以下是我的配置示例：

# 编辑 PHP-FPM 配置文件
sudo vim /etc/php/7.4/fpm/pool.d/www.conf

在配置文件中找到或添加以下配置项：

; 启用慢日志
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log

踩坑提示：确保日志目录有写入权限，我曾在权限问题上浪费了不少时间：

sudo mkdir -p /var/log/php-fpm
sudo chown www-data:www-data /var/log/php-fpm

配置完成后，重启 PHP-FPM 服务：

sudo systemctl restart php7.4-fpm

分析慢日志内容

启用慢日志后，当有脚本执行超过 5 秒时，日志中就会出现类似这样的记录：

[21-Nov-2023 14:30:15]  [pool www] pid 12345
script_filename = /var/www/html/api/user.php
[0x00007f8a5a3b12a0] sleep() /var/www/html/api/user.php:25
[0x00007f8a5a3b11f0] getUserProfile() /var/www/html/api/user.php:15
[0x00007f8a5a3b1150] main() /var/www/html/api/user.php:35

从上面的日志可以看出，问题出现在 user.php 第 25 行的 sleep() 函数。在实际项目中，这可能是数据库查询、文件操作或外部 API 调用。

实战优化案例

在我的案例中，慢日志显示问题出现在一个用户信息查询的函数中。进一步分析代码，发现了问题所在：

// 优化前的代码
function getUserProfile($userId) {
    $profile = $db->query("SELECT * FROM users WHERE id = $userId");
    
    // 嵌套查询用户的其他信息
    $posts = $db->query("SELECT * FROM posts WHERE user_id = $userId");
    $comments = $db->query("SELECT * FROM comments WHERE user_id = $userId");
    
    return [
        'profile' => $profile,
        'posts' => $posts,
        'comments' => $comments
    ];
}

这个函数存在典型的 N+1 查询问题。优化后的版本使用了 JOIN 查询和缓存：

// 优化后的代码
function getUserProfile($userId) {
    // 使用缓存
    $cacheKey = "user_profile_{$userId}";
    if ($cached = $cache->get($cacheKey)) {
        return $cached;
    }
    
    // 合并查询
    $sql = "SELECT u.*, 
                   COUNT(DISTINCT p.id) as post_count,
                   COUNT(DISTINCT c.id) as comment_count
            FROM users u
            LEFT JOIN posts p ON u.id = p.user_id
            LEFT JOIN comments c ON u.id = c.user_id
            WHERE u.id = ?
            GROUP BY u.id";
    
    $result = $db->query($sql, [$userId]);
    
    // 缓存结果
    $cache->set($cacheKey, $result, 3600);
    
    return $result;
}

性能优化效果验证

优化后，我们再次监控慢日志，发现相关请求已经从慢日志中消失。通过 New Relic 监控可以看到，该接口的响应时间从平均 3.2 秒降低到了 120 毫秒，性能提升了 26 倍！

# 监控慢日志变化
tail -f /var/log/php-fpm/slow.log | grep "user.php"

总结与建议

通过这次经历，我总结了几个关键点：

• 生产环境务必启用 PHP-FPM 慢日志，阈值建议设置为 3-5 秒
• 定期分析慢日志，建立性能基线
• 重点关注数据库查询、外部 API 调用和文件操作
• 优化后要通过监控工具验证效果

性能优化是一个持续的过程，希望我的经验能为你提供一些参考。如果你在实践过程中遇到问题，欢迎在评论区交流讨论！