Nginx image_filter与PHP GD图片缩放对比：CPU消耗、性能差异及选型建议

我之前在搭建实时图片缩放服务的时候，专门针对这俩方案做过压测和对比，刚好能分享下实际的表现和选型建议：

CPU Resource Consumption #

毫无疑问，PHP GD的CPU消耗要显著高于Nginx image_filter。原因很简单：

• Nginx的image_filter是直接基于GD库开发的C语言模块，运行在Nginx的worker进程内部，没有额外的解释层开销，调用GD库的方式是最直接的原生调用。
• 而PHP GD是通过PHP解释器来调用GD库，每次请求都要经历PHP虚拟机初始化、加载GD扩展、解析执行脚本代码这些额外步骤，这些都会带来额外的CPU消耗。

Performance Gap Percentage #

我当时用单核心服务器（Intel i5-8250U）做压测，处理的是将100x100的JPG图片缩放到50x50的场景：

• Nginx image_filter的QPS能稳定在850左右，CPU使用率维持在30%-35%。
• PHP-FPM（配合简单缩放脚本）的QPS只有300上下，CPU使用率直接冲到75%-80%。

换算下来，PHP GD的CPU消耗大概是Nginx image_filter的2.2-2.5倍，而性能（QPS）只有Nginx的35%左右。如果是更复杂的图片操作（比如加水印、裁剪），这个差距会更大。

How to Choose? #

要根据你的业务场景来选：

• 优先选Nginx image_filter：如果只是做基础的实时缩放、裁剪、旋转、调整画质这类纯图片处理操作，没有复杂的业务逻辑绑定。它的优势是轻量、低消耗、部署简单，不用依赖PHP-FPM服务，能减少整个服务架构的复杂度。
  举个简单的Nginx配置示例：

  location /resize {
      image_filter resize 100 100; # 保持比例可写为`100 -`，只限制宽度
      image_filter_jpeg_quality 80;
      root /var/www/images;
  }
  

• 必须用PHP GD：如果你的图片处理需要结合业务逻辑，比如根据用户权限动态生成不同尺寸的图片、从数据库拉取水印文字叠加、或者需要对图片做自定义的像素级处理，Nginx模块做不到这么灵活的业务扩展。
  简单的PHP GD缩放脚本示例：

  <?php
  $srcPath = $_GET['src'];
  if (!file_exists($srcPath)) {
      header("HTTP/1.1 404 Not Found");
      exit;
  }
  $source = imagecreatefromjpeg($srcPath);
  $origWidth = imagesx($source);
  $origHeight = imagesy($source);
  $targetWidth = 100;
  $targetHeight = intval($origHeight * ($targetWidth / $origWidth));
  
  $destImage = imagecreatetruecolor($targetWidth, $targetHeight);
  imagecopyresampled($destImage, $source, 0, 0, 0, 0, $targetWidth, $targetHeight, $origWidth, $origHeight);
  
  header('Content-Type: image/jpeg');
  imagejpeg($destImage, null, 80);
  
  // 释放资源
  imagedestroy($source);
  imagedestroy($destImage);
  ?>
  

• 混合场景：如果既有基础缩放需求，又有部分复杂业务处理，可以考虑让Nginx先完成基础缩放，再将图片传递给PHP做后续的业务绑定处理，这样能最大化降低整体CPU消耗。

内容的提问来源于stack exchange，提问作者Future King