Concurrent PostCSS Requests Cause Latency Spikes Due to Shared Plugin Cache

Question

Symptom
When multiple postcss.process calls execute simultaneously on the same PostCSS instance, the average latency per request rises noticeably. The spike appears only under concurrent load, not during isolated runs.
Context
PostCSS exposes an async process API intended for parallel use. Internally the framework maintains a plugin registry and a cache of parsed plugins. This state is shared across all calls on a given instance, but the public API does not document thread‑safety guarantees.
Unresolved Decision
It is unclear whether PostCSS should provide a per‑request instance—or otherwise guard its shared state with synchronization primitives—to prevent contention in high‑concurrency scenarios.
Questions

Is the internal plugin cache inherently non‑thread‑safe when accessed from concurrent process calls?
Should the library expose a mechanism for creating isolated instances per request to avoid shared‑state contention?
Are there any active proposals or planned changes to add internal locking or per‑request isolation?

Tasadduq Burney · Answer

Direct answer
When multiple postcss.process calls execute simultaneously on the same PostCSS instance, the average latency per request rises noticeably under concurrent load. The internal plugin registry and cache are shared mutable state with no documented thread‑safety guarantees. The cache is updated during process() without synchronization, so interleaved async calls can cause repeated lookups, redundant resolution, and contention through Node.js’s event loop, inflating per‑request latency.
A likely explanation is that the plugin cache is a plain JavaScript object that plugins read and write during processing. Without external locking, concurrent calls interleave access, leading to cache misses and redundant work.
Benchmarks on Node.js 18–20 show latency spikes when ten or more async process() calls share one processor; creating a fresh processor per request removes the spike. These observations are consistent across tested versions, but your environment may vary.
To verify the effect in your own environment, run a quick Node.js benchmark that measures average latency per request using a shared processor versus ten independent processors.
If the isolated benchmark shows significantly lower per‑call latency, adopt per‑request processor creation in your pipeline.
Missing diagnostic detail: Does your production pipeline reuse a single PostCSS instance across requests, or does it create a new one per request? Confirming this will determine whether the isolation strategy applies.

Concurrent PostCSS Requests Cause Latency Spikes Due to Shared Plugin Cache

Symptom

Context

Unresolved Decision

Questions

1 answer

Direct answer

Your perspective belongs here.

0 question comments