4 Commits

Include renames

Author	SHA1	Message	Date
sneak	0be3333730	Default max_concurrent_processing to half the CPUs pixa sees (closes #242) ... The default was one image per CPU Go uses, and a container with no CPU limit sees every CPU of the host. It is now half of runtime.GOMAXPROCS(0), rounded down and at least 1, from imageprocessor.DefaultMaxConcurrentProcessing, which both the config and imageprocessor.New use. The two existing tests of the default expect the new one, as the owner allowed on the issue. "Running under upaas" gives the worst-case memory, with a per-image peak of about 1.6 GiB measured on pixad for an 8192x8192 source in each output format, and tells the operator to set PIXA_MAX_CONCURRENT_PROCESSING and PIXA_UPSTREAM_CONNECTIONS to fit the container's memory. Model: opus-5-5	2026-10-15 09:36:15 +00:00
sneak	198f92a5f8	Test that max_concurrent_processing defaults to half the CPUs ... An omitted max_concurrent_processing, and New given none, must be half the CPUs Go uses, rounded down, and at least 1. The tests set GOMAXPROCS to 1, 2, 3 and 8 and fail until the default changes (#242). Model: opus-5-5	2026-10-15 09:05:01 +00:00
sneak	5c795429b8	Test that an invalid PIXA_MAX_CONCURRENT_PROCESSING aborts startup ... An empty, fractional, negative or non-numeric value must abort startup naming the variable and the key, never fall back to the default. The config loader already refuses these; this pins it before the default changes (#242). Model: opus-5-5	2026-10-15 09:04:40 +00:00
clawbot	baf457d21e	Bound concurrent image processing and upstream fetches (closes #64) ... Nothing bounded total in-flight work, so a burst of cache misses across hosts could exhaust memory. Two settings now do: max_concurrent_processing (default the CPUs Go uses) and upstream_connections (default 64, beside the per-host limit). A request that finds either full waits up to 10 seconds, then gets 503; a slot is released on every path. No request holds source bytes while it waits: a cached source is read only after the processing slot is taken, and a fetched one only while it holds its upstream connection. libvips runs one worker thread per image with its operation cache off. Both waits count toward downstream_timeout, as the README says. Model: opus-5-5	2026-09-29 10:32:16 +02:00