[wp-trac] [WordPress Trac] #58202: php-fpm7.4: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1868.

[WordPress Trac]

#58202: php-fpm7.4: time limit exceeded `Operation canceled' @
fatal/cache.c/GetImagePixelCache/1868.
--------------------------+-----------------------
 Reporter:  dsar          |       Owner:  antpb
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  6.2.3
Component:  Media         |     Version:  6.2
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------

Comment (by matt_fw):

 We were affected by this issue. We solved it by creating a separate PHP-
 FPM pool for `async-upload.php`, directing traffic to it, and setting its
 `pm.max_requests = 1` and `pm.max_servers = 4`. The important part is
 `pm.max_requests = 1` to reset ImageMagick's cache timer on each request.

 However, after reading through the ImageMagick resource handling code (
 https://github.com/ImageMagick/ImageMagick/blob/a531d28e31309676ce8168c3b6dbbb5374b78790/MagickCore/resource.c#L1496
 ) I think it's enough to call `Imagick::setResourceLimit(
 Imagick::RESOURCETYPE_TIME, $limit );` on each request, even if the
 already set value is the same. In WP 6.2.2 the call is executed only when
 `max_execution_time < imagick_timeout`, but that happens only on the first
 call to `Imagick::set_imagick_time_limit()` within each PHP-FPM process.

 Calling `Imagick::setResourceLimit( Imagick::RESOURCETYPE_TIME, $limit );`
 resets ImageMagick `cache_epoch = 0` (see
 https://github.com/ImageMagick/ImageMagick/blob/a531d28e31309676ce8168c3b6dbbb5374b78790/MagickCore/cache.c#L4847)
 and effectively makes ImageMagick's cache act as if it was request-based.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58202#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform