UserCache\Cache Performance Report

Compares UserCache\Cache with APCu/igbinary, APCu/php and Yac/php on the same machine. Every value is the median across 3 runs, with all measurements pinned to CPUs 0-3. Generated at 2026-09-30T08:35:35+00:00.

Related report: FrankenPHP persistence comparison

UserCache vs APCu/igbinary

Speedup is the APCu/igbinary median divided by the UserCache median from the same measurement session; above 1.00x UserCache is faster. FPM rows pair UserCache with the run that used the same APCu serializer. The geometric mean weighs every workload equally; Lowest and Highest name the workloads with the smallest and largest speedup.

Speedup per workload

Bulk read, median per batch

Multi-key reads: UserCache fetchMultiple() against APCu/igbinary fetching an array of keys, with per-key loops for reference. Speedup compares the two multi-key calls.

UserCache vs FrankenPHP zval.h reference

UserCache compared with a reference cache built on the official FrankenPHP zval.h helpers, running in the same persistent FrankenPHP worker threads. PHP fetch batches show the speedup, reference time ÷ UserCache time; HTTP rows show the throughput ratio, UserCache ÷ reference. Above 1.00x UserCache is faster in both. Each value comes from randomized matched pairs; a case counts, and its cell is colored, only when the paired bootstrap 95% interval excludes 1.00x. Per-case timings, memory, A/A noise and provenance are in the FrankenPHP persistence report.

Mode worker · micro 15 pairs × 2 sessions · A/A 15 pairs · HTTP 5 rounds × 5 s · CPUs 0-3 · FrankenPHP 51e6246e71f3 · measured 2026-09-30T07:54:36+00:00

A/A runs (the reference measured against itself) show the noise floor: their medians range from 0.943x to 1.132x. Cases marked † have A/A noise above ±2%, so differences of that size are not meaningful there.

PHP fetch batches, speedup (reference time ÷ UserCache time)

HTTP worker scaling, throughput ratio (UserCache ÷ reference)

The Go HTTP client and FrankenPHP workers share the pinned CPU set, so intervals widen as workers grow. With one operation per request, the cache call is a small part of each request.

CLI Repeated Read

A warm CLI process stores each payload once, then times fetch() plus a small access probe on the fetched value. Each run times 2,000 operations × 12 iterations after 2 warmup iterations. Cells show the median µs per operation, with the mean below it.

CLI Store

Times store() of each payload, cycling over 32 keys. Slower stores are an intentional trade-off for faster reads (note). Each run times 200 operations × 6 iterations after 2 warmup iterations. Cells show the median µs per operation, with the mean below it.

FPM One Fetch Per Request

Each HTTP request through nginx and php-fpm fetches the payload once, so every fetch is the first one in its request. Each backend serves 180 requests after 20 warmup requests, 5 at a time. Time is measured inside PHP per fetch. Cells show the median µs, with the mean and interquartile range below; Workers is the number of php-fpm workers that served the requests. APCu can use one serializer per server, so there is one run per APCu serializer; UserCache and Yac were measured again in each run.

FPM One Fetch Per Request (APCu serializer=php)

FPM One Fetch Per Request (APCu serializer=igbinary)

FPM Hot Read

Each HTTP request through nginx and php-fpm fetches the same payload 100 times, so this measures repeated fetches within one request. Each backend serves 24 requests after 4 warmup requests, 5 at a time. Time is measured inside PHP per fetch. Cells show the median µs, with the mean and interquartile range below; Workers is the number of php-fpm workers that served the requests. APCu can use one serializer per server, so there is one run per APCu serializer; UserCache and Yac were measured again in each run.

FPM Hot Read (APCu serializer=php)

FPM Hot Read (APCu serializer=igbinary)

Memory Usage

Memory per workload and backend, measured in CLI outside the timed loops; smaller is better. The smallest nonnegative cache and per-fetch values are highlighted independently, including ties.

Shared Memory Capacity and Baseline

Reserved capacity and used memory before storing the workload, excluded from the per-value cache delta. The baseline represents startup overhead with the default isolated CLI workers. Values below are medians across workloads.

Resident Payload Probe

How close a UserCache fetch gets to data that is already in the request. Resident direct access runs only the access probe on a payload that already exists in the request; UserCache fetch + access is the CLI repeated read time. The difference estimates what the fetch itself costs (note).

Bulk Read

Each run primes the key set, then times fetching all keys as one batch: a multi-key call (UserCache fetchMultiple(), APCu apcu_fetch(array), Yac get(array)) and a per-key loop. Times are µs per batch; the fastest median is green.

Bulk Read: 32 Keys

Bulk Read: 128 Keys

Workloads

What each workload stores and reads. Workload names in the result tables link here.

Notes

Already-resident data is a baseline

The resident table does not include UserCache store time. It compares direct access to an already-resident payload with fetching a previously stored UserCache entry and running the same access probe. The difference estimates fetch and materialization overhead after the value has already been stored. The primary comparison for UserCache is against APCu/php and APCu/igbinary when reconstructing object-heavy payloads, not against literals already resident in the request.

Slower stores are an expected trade-off for faster reads

Store workloads are shown to make the write-side cost explicit. APCu-style shared caches are usually used for read-heavy paths, where a stored value is read many times. Store throughput is an intentional trade-off in this design, not the metric it is optimized for.

Environment

Data

The numbers on this page are embedded in it as JSON, in <script id="embedded-result" type="application/json"> (schema user_cache_benchmark_report, version 1). summary holds the values behind the cards and summary tables; results holds each input file below, unchanged. When results.cli_write is null, the store rows are in results.cli_read.data.write. Source paths are relative to the benchmark harness repository.

JSON.parse(document.getElementById('embedded-result').textContent)