Meet pm=synconix: the PHP-FPM process manager built for real-world speed

Fast PHP hosting has always involved an awkward choice. You can keep many workers alive and enjoy predictable response times, but pay for them in RAM. Or you can keep almost nothing running, save resources, and accept that the next traffic spike may arrive before PHP is ready.

We wanted a better answer, so we built a fourth native PHP-FPM process manager: pm=synconix.

Synconix keeps PHP ready when it matters, creates capacity quickly when traffic grows, and releases that capacity as soon as it is no longer useful. It is not a page cache, not an external autoscaling script, and not a renamed dynamic profile. The decision engine runs directly inside PHP-FPM.

In practice, the pool maintains readiness during demand and releases unused capacity after pressure subsides.

How the process managers differ

• static keeps fixed capacity ready for predictable latency, but every configured worker consumes resources during quiet periods.
• dynamic maintains a configurable range of spare workers, which requires careful tuning and can retain unnecessary capacity.
• ondemand minimizes idle memory, but a quiet pool can fall to zero and add process-creation latency when traffic returns.
• synconix keeps a warm base, expands from observed pressure and releases capacity quickly; it requires the native Synconix PHP-FPM build.

Static capacity provides readiness at a continuing memory cost, while an empty pool saves memory but adds worker startup latency. Synconix evaluates that balance continuously from the pool's observed state.

The adaptive idea

1. It keeps a real warm floor

By default, an active Synconix pool keeps at least one initialized PHP worker ready to accept a request. That worker already has PHP, its extensions, and the FPM runtime loaded. The pool therefore avoids the full zero-worker startup path used by a completely idle ondemand pool.

The warm floor is adaptive. If a pool repeatedly proves that it needs more immediate capacity, Synconix can temporarily keep additional workers ready. When the traffic pattern disappears, the floor gradually returns to its economical baseline.

2. It reacts in milliseconds, not maintenance cycles

Synconix watches socket accept events, listen queue pressure, active workers, idle workers, and workers that are still starting. It can create workers in adaptive batches instead of waiting for a later maintenance cycle to add capacity one process at a time.

The batch size is bounded by pm.max_children and informed by available CPU capacity and the current type of pressure. This allows fast, bounded expansion while respecting the server's memory ceiling.

3. It distinguishes useful concurrency from blind spawning

A growing queue does not always mean that more PHP workers are the right answer. A request may be CPU bound, or it may simply be waiting on MariaDB, storage, or an external API.

Synconix samples request wall time and CPU time, understands the CPU capacity exposed by affinity and cgroup v2 limits, and classifies pressure before expanding aggressively. CPU work can justify a fast but bounded burst. Application wait can justify enough concurrency to keep the service moving, but worker creation remains bounded so one slow dependency cannot create server-wide pressure.

4. It remembers recurring bursts, briefly

Traffic rarely arrives as one perfectly shaped wave. Real sites produce AJAX groups, checkout calls, API bursts, crawler clusters, and several assets that reach PHP almost together.

Synconix recognizes useful recurring pressure and can retain a small number of proven workers for a short period. It does not spawn workers merely to fill that temporary reserve. It only keeps capacity that already demonstrated a purpose, then releases it when the pattern expires.

5. It recycles workers without making the pool cold

Worker recycling protects long-running PHP services from memory growth, allocator fragmentation, and extension or application leaks. The traditional downside is that several workers can reach pm.max_requests together and leave a temporary capacity hole.

Synconix spreads recycle points with deterministic jitter and prepares replacement capacity before a busy worker exits when possible. The goal is to recycle safely without creating a temporary capacity gap.

Not another cache layer

Synconix does not store or replay HTML responses. Every PHP request still executes normally. Sessions, cookies, logged-in users, shopping carts, POST requests, uploads, database writes, and application permissions keep their original semantics. Session and application state therefore retain their normal isolation and request semantics.

This distinction matters for WordPress and WooCommerce sites, where the most important requests are often exactly the ones that bypass web cache. Synconix improves PHP worker readiness for those requests while preserving their dynamic behavior.

Watch these numbers

We test Synconix with OPcache disabled first. The process manager must stand on its own, including for applications that cannot safely use OPcache.

In a representative ten-application, OPcache-off real-world smoke matrix, Synconix used 62.47% less RSS and reached 75% fewer peak workers than static. In the same run, it delivered 33.88% lower p95 latency and 33.44% lower p99 latency than dynamic.

Across broader clean-state, multi-version matrices, median peak summed-RSS savings against static were commonly between 56% and 68% with OPcache disabled. Results vary by PHP version, application, route, concurrency, database behavior, and hardware, so performance is reported per workload rather than as one universal latency percentage. What the tests consistently demonstrate is the result we designed for: static-class readiness without a static-sized memory bill.

The latest recurring-burst generation also reduced worker births and exits by 41.67% to 50%, while reducing PHP-FPM master CPU consumption by roughly 19% compared with the previous Synconix generation in the controlled burst matrix. That is less time spent managing processes and more time available for useful work.

For context, p95 is the response time met or beaten by 95% of measured requests. We track p95 and p99 because averages can hide the slowest requests customers experience.

OPcache helps, but it is not the premise

Synconix works with OPcache off. When in-memory OPcache is compatible with the application, it becomes an additional acceleration layer: Synconix keeps execution capacity ready, while OPcache avoids recompiling unchanged PHP scripts on every request.

In an include-heavy warm-code test containing 256 PHP files, enabling in-memory OPcache reduced Synconix p95 from 25.853 ms to 9.266 ms, an improvement of 64.16%. Pure arithmetic workloads showed no guaranteed gain, and the first request after a fresh master still had to populate the shared cache. That is why OPcache remains optional, measured, and workload dependent rather than being used to hide process-manager behavior.

We also keep opcache.file_cache out of the default design. Synconix does not need a disk bytecode cache to function correctly or quickly.

Designed for a hosting fleet

The native implementation has been built and regression-tested across PHP 5.6 through PHP 8.5. The test program covers standard PHP responses, WordPress, cookies and cache-bypass routes, sessions, POST requests, large multipart uploads, slow requests, database delay, queue growth, worker recycling, graceful reloads, mixed process managers, and OPcache both off and on.

The configuration can remain deliberately simple. For example:

pm = synconix
pm.max_children = 30

pm.max_children remains a workload and account-specific safety ceiling. It does not mean that thirty workers stay resident. Synconix automatically selects the starting floor, spare range, idle behavior, recycle policy, adaptive warm window, and burst width unless an operator deliberately overrides them.

If a pool uses static, dynamic, or ondemand, Synconix stays out of the way completely. There is no external kill switch and no hidden controller translating the configuration. The selected process manager is the process manager PHP-FPM runs.

A native control loop

Modern hosting platforms have shown why hot process groups and fast process allocation matter in commercial hosting. Synconix applies those principles through a native adaptive manager inside our PHP-FPM builds.

It was built around the operational realities of our platform: per-user services, per-version pools, cgroup controls, and standard PHP application semantics. The result is that native FPM no longer has to choose between keeping a large static process group alive and allowing an active site to go completely cold.

The configuration line

pm=synconix is our answer to a practical hosting problem: keep PHP ready, scale with evidence instead of guesswork, protect the server during pressure, and return resources quickly when the work is done.

The design does not depend on page caching, permanently resident peak capacity, or extensive per-site tuning.

The result is a process manager that maintains readiness, expands under measured pressure, and releases unused capacity promptly.