UserCache vs FrankenPHP zval.h Reference

Compares UserCache\Cache with a benchmark reference cache built on the official FrankenPHP zval.h helpers, both running in the same persistent FrankenPHP worker threads. The reference is not a public native FrankenPHP cache API. Measured at 2026-09-30T07:54:36.579770+00:00.

Measured run — all selected samples validated · mode worker · micro 15 pairs × 2 sessions · A/A 15 pairs · HTTP 5 rounds × 5 s · CPUs 0-3 · FrankenPHP 51e6246e71f3

Related report: UserCache\Cache performance report (APCu and Yac)

Summary

PHP fetch batch rows compare time inside one PHP execution as a speedup; HTTP rows compare end-to-end throughput. Above 1.00x UserCache is faster in both. Counts use the paired bootstrap 95% interval of each case; the geometric mean weighs every case equally.pairing and statistics note

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)

PHP fetch batches — worker mode

Median time per fetch in a timed batch, including the common PHP fetch loop and observation or mutation. Seed, setup and warmup stay outside the batch. The speedup cell shows its 95% interval and the speedup of each session; A/A noise is how far the same case measured reference against reference moved from 1.00x.workload note

HTTP worker scaling

Real HTTP requests to FrankenPHP workers. Throughput ratio is the UserCache throughput divided by the reference throughput; above 1.00x UserCache is faster. Closed-loop clients equal twice the worker count, with all workers warmed before timing. The array fixture has TTL 3600; the scalar fixture has TTL 0. Both share 32 keys.HTTP scope note

Throughput

Time inside PHP

Median PHP batch time per cache operation within each request, with the PHP thread CPU per operation for the whole request. Speedup is the reference median divided by the UserCache median. These medians have no paired interval, so they are not colored; the lower median is in green text. With one operation per request, each batch is the first fetch of its request and includes per-request setup, and the cache call is a small part of the request (compare the thread CPU with the HTTP latency above), so throughput mostly reflects HTTP and client overhead.

Memory usage

The supplied micro host configures UserCache SHM capacity at 256 MiB, entries_hint at 65,536 and PHP memory_limit at 768 MiB. The HTTP host configures SHM at 32 MiB and memory_limit at 256 MiB, leaving entries_hint at the extension default. These are configured capacities/limits, separate from the measured used-byte snapshots below; neither is process RSS.

cached data: for UserCache, shared memory used above the empty segment (the empty segment already holds the entry tables sized by entries_hint; the reference sample of the same host shows it), including keys and allocator overhead; for the reference, requested persistent helper allocations, excluding allocator rounding and some wrapper metadata. PHP heap: sampled worker PHP heap after the reads, above the heap after reset, including warm prototypes and bookkeeping such as UserCache per-key records. PHP peak: peak heap above the heap after reset. Fetched values are released each iteration. These categories cannot be added as if they described equal allocations. The smaller value of each category is highlighted, including ties.

PHP fetch batch data sets

HTTP fixtures at the end of each case

HTTP end status samples one worker PHP heap; it is not total heap across all workers or process RSS. Shared/persistent stores are process-wide.

A/A measurement noise

The same reference wrapper measured against itself with the same pairing, as second run time ÷ first run time. A UserCache speedup closer to 1.00x than this spread is not a difference; A/A medians beyond ±2% are marked †.

Raw helper diagnostic — no cache speed ratio

Reads call persistent_zval_to_request from an already persisted value. They do not persist/free per iteration, perform key lookup, implement TTL or share the warm wrapper prototype cache. The 32,768-key label records the surrounding workload shape; the raw helper still has one source value. This is an allocation/copy lower-level diagnostic, not a public FrankenPHP cache comparison, and never enters the rankings above.

Environment

The source inputs archive includes the exact PHP input tree, harness assets, built source/config files and measurement producer snapshots, and stays in the local measurement workspace. The aggregate result, including provenance and the build manifest, is embedded in this HTML; raw JSONL samples and logs are not published.

Data and provenance

The aggregate result.json is embedded in this page unchanged, in <script id="embedded-result" type="application/json"> (schema_version 1). Its ratios keep the measured direction: micro[] and aa[] rows hold paired_ratio as UserCache time ÷ reference time (this page shows its reciprocal as the speedup) with median_ratio_ci95, and http[] rows hold paired_throughput_ratio as UserCache ÷ reference. Per-backend medians are under backends.user_cache and backends.reference.

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

Official helper: pinned FrankenPHP zval.h. Build manifest and binary/library/fixture SHA-256 values are stored in the aggregate JSON.

{
  "created_at": "2026-09-30T07:54:36.579770+00:00",
  "configuration": {
    "build_dir": "/workspaces/php-src/php-user_cache_benchmark_harness/runtime/frankenphp",
    "output_dir": "/workspaces/php-src/php-user_cache_benchmark_harness/results/persistence-20260930T075436.577836Z",
    "output": "/workspaces/php-src/php-user_cache_benchmark_harness/BENCH_RESULT_PERSISTENCE.html",
    "build": false,
    "php_src": "/workspaces/php-src",
    "frankenphp_src": null,
    "jobs": 2,
    "quick": false,
    "pairs": 15,
    "rounds": 5,
    "sessions": 2,
    "seconds": 5,
    "cpus": "0-3",
    "seed": 1701,
    "stage": "all",
    "mode": "worker",
    "payloads": [
      "null",
      "bool",
      "int",
      "double",
      "string32",
      "string300",
      "string4k",
      "string64k",
      "packed8",
      "packed512",
      "hash32",
      "nested"
    ],
    "workers": [
      "1",
      "2",
      "4"
    ],
    "operations": [
      "1",
      "100"
    ],
    "kinds": [
      "array",
      "scalar"
    ],
    "modes": [
      "read",
      "mixed"
    ]
  },
  "environment": {
    "platform": "Linux-7.0.14-orbstack-00380-ga7e0a2dc9535-aarch64-with-glibc2.39",
    "machine": "aarch64",
    "python": "3.12.3 (main, Aug 31 2026, 10:18:26) [GCC 13.3.0]",
    "cpu_count": 10,
    "affinity": [
      0,
      1,
      2,
      3,
      4,
      5,
      6,
      7,
      8,
      9
    ]
  },
  "binaries": {
    "bench": {
      "path": "/workspaces/php-src/php-user_cache_benchmark_harness/runtime/frankenphp/bin/frankenphp-bench",
      "sha256": "8da32f12b5fa65223d78f037b0388cfd8201ccfd7062e1a50634cf428d6d554d"
    },
    "scale": {
      "path": "/workspaces/php-src/php-user_cache_benchmark_harness/runtime/frankenphp/bin/frankenphp-scale",
      "sha256": "545e5ddebd42b75cbdddb0b99dfe84338b423a446a1c58abcdd55585775f6ca6"
    }
  },
  "php_libraries": {
    "/workspaces/php-src/php-user_cache_benchmark_harness/runtime/frankenphp/install/lib/libphp.so": "2bebc91ccd5d1086684691a6bffbcd030ab9dbab7b8f17cae2ca594042bf1106"
  }
}

Notes

Measurement contract

Micro/A/A execution mode: worker. Worker mode retains the PHP execution between HTTP requests; classic mode starts a fresh PHP request for each micro/A/A HTTP sample. Each sample performs its seed and warmup in that same PHP execution. HTTP scaling always uses persistent workers, independently of this option.

Worker-mode samples must have zero outstanding graph pins. Classic samples record a nonnegative pin count during the PHP request, when borrowed shared values may legitimately remain pinned; this observation does not verify their release after request shutdown.

Workloads

Dynamic payloads are created at runtime, with OPcache and JIT disabled. Seed/persist, setup and warmup are outside the timed fetch batch. Both cache wrappers include lookup, generation/TTL invalidation and warm PHP-heap COW caching; the raw helper reads an already persisted source and excludes cache lookup. Cold means the first fetch after store, including any store-time string COW seeding; there is no cold one-key row. The retained integer mutate-flag case does not mutate integers.

Common cases cover null, boolean, integer, double, strings and nested arrays; object hooks, references, aliases/cycles and UserCache-specific native object support are outside this reference comparison. Mutation checks verify the cached source remains unchanged. Fetched values are released each iteration: these memory figures do not measure retaining an unbounded list of returned values. Stores in the mixed HTTP workload are reported together with reads; this is not an isolated store benchmark.

Pairing and statistics

Independent hosts run sequentially. Micro samples use randomized paired backend order; HTTP pairs alternate order within each case. A/A runs use the same reference wrapper twice to expose local noise. Every case stays visible, including cases within the interval and cases the reference wins. Raw scalar/immutable-pointer helpers can be lower bounds that a full cache cannot beat. The supplied fixtures are dynamic; OPcache-immutable fixtures are not mixed into these results.

Timing tables use per-backend medians. Ratios are medians of matched pairs, not ratios of pooled means; intervals are a paired bootstrap 95% interval for the median when at least two pairs exist. Intervals from very few pairs are exploratory. Lower latency/CPU is better; higher HTTP throughput is better.

HTTP scope

Request and operation rates are separate; all individual response samples and status/pin checks are retained.

The loopback HTTP client and server run in the same Go process and share its CPU affinity. HTTP throughput includes client, server and networking overhead; it is not an isolated remote-client server-capacity result. Thread CPU measurements cover the PHP thread only, not total Go host/client CPU. With more workers, the client and the workers compete for the same CPUs and intervals widen.