UserCache\Cache Performance Report

Generated at 2026-07-15T04:32:18+00:00. Times are in microseconds; lower is faster.

Environment

CLI Repeated Read

CLI Store

FPM One Fetch Per Request (APCu serializer=php)

FPM One Fetch Per Request (APCu serializer=igbinary)

FPM Hot Read (APCu serializer=php)

FPM Hot Read (APCu serializer=igbinary)

Resident Payload Probe

Bulk Read: 32 Keys

Bulk Read: 128 Keys

Artifacts

Workloads

Click a workload name in the result tables to jump to its description. CLI repeated read stores the payload before timing, then measures only fetch() plus the access probe. CLI store repeatedly stores the payload over the configured key space. Resident direct access runs only the access probe against an already-resident payload. FPM rows run the same fetch path through nginx/php-fpm workers. Bulk read primes multiple keys, then measures fetching the whole key set.

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.