Skip to content

Document the image processing limits - #1208

Open
ajwild wants to merge 15 commits into
image-upload-temp-directoriesfrom
image-processing-limits
Open

Document the image processing limits#1208
ajwild wants to merge 15 commits into
image-upload-temp-directoriesfrom
image-processing-limits

Conversation

@ajwild

@ajwild ajwild commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Documents the image processing limits added in these server PRs:

Based on #1207, which introduces the section it extends — review that one first.

  • Documents the new mediaLibrary.images.processing.timeout and mediaLibrary.images.processing.maxConcurrentResizes options.
  • Adds a Sizing the Processing Limits section: how the two concurrency options relate to Node.js' thread pool, why os.availableParallelism() rather than os.cpus().length is the number to size against, and recommended values per container CPU limit.
  • Describes maxConcurrentProcesses as covering an upload end to end, which is what it does as of server PR #9865.
  • Notes that uploadProcessingDirectory now holds every transformed upload rather than only large animated ones, and corrects the volume sizing guidance: the worst case is 2GB rather than 300MB for the maxFileSize: 100mb that customers commonly configure.
  • Adds a release-2026-09 feature entry covering all of the above plus the raised upload timeout, the shared job for concurrent requests for the same variant, and the one-thread-per-image change.

ajwild and others added 15 commits August 12, 2026 15:33
Covers the new processing.timeout and processing.maxConcurrentResizes options,
the raised upload timeout, and the one-thread-per-image change.
Both limits and the thread pool they share have to be set together, and none of
them can be derived from the host's core count.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The legacy transform runs while the result is streamed to storage, outside the
maxConcurrentProcesses queue, so the thread pool is the only limit on it — which
makes a large thread pool a memory risk rather than a free win.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The thread pool, not the two concurrency options, is what decides how many
images are processed at once, so the sizing advice follows from both together.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Link both configuration sections instead of restating how the limits interact.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The per-frame limit and the frame count multiplied out to far more than either
suggests, which is what the new option bounds.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The per-image figure was measured at roughly 200MB. It is about 4 bytes
per pixel of every frame, so a 200 megapixel animation takes 800MB, and
the sizing guidance was recommending combinations that exceed a
container's memory by an order of magnitude.
Still images stream, so their cost follows the variant being produced
rather than the source. Only one of the two paths decodes anything:
variants with use2025Behavior, uploads without it, never both.
maxTotalResolution bounds raster work to well under 20 seconds, so the
hour-long processing the timeout was described as preventing is no longer
reachable. SVG rendering cost is not measured by any pixel limit.
The headroom under the timeout is a function of maxTotalResolution, which
is meant to be raised. Processing time scales with it linearly, so the
timeout is what still holds at a high or unbounded limit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant