Snapshot

[arnaud-lb]

This implements snapshotting of the process's state. The snapshot can be restored in a subsequent request, to save initialization time.

This adds two functions:

function snapshot_state(): void;

/* Return true if the state was restored */
function restore_state(): bool;

Example usage:

if (!restore_state()) {
    $kernel = new Kernel();
    $kernel->boot();
    snapshot_state();
}

$kernel->handle();

What is restored

• Declared classes, functions, constants
• Global variables, static properties, static variables
• Error and exception handlers
• Autoloaders
• List of included files (for require_once)

Internal objects

Internal objects don't need special support as long as they use only the zend heap (e.g. no native allocations, kernel resources). However they need to be marked as such. The current branch marks a few internal classes as safe because these are used in the symfony-demo benchmark. snapshot_state() will throw if an unsupported object is found.

Snapshots are private to a php instance / process, so it may be possible to support objects with native allocations and kernel resources. In some case it may be acceptable that the state of the native allocation / kernel resource changes after the snapshot (e.g. for streams or database connection), but for others it might not (e.g. DOM objects), in which case we may need to separate/clone the resource.

Design

The basic idea is that we copy the heap to a separate buffer. Later, we restore the state by copying back the buffer to the old location. We don't have to copy/relocate individual zvals and other state: We just copy heap chunks. We then update the global symbol table.

Snapshotting

We make a copy of every heap chunk (2MiB each), and prevent the heap from releasing these chunks later (to reserve the address space).

copies := []
for chunk in heap.chunks:
    copies[] := (chunk, memdup(chunk, MM_CHUNK_SIZE))
    chunk.preserve := true

We also copy symbol tables (variables, classes, functions, constants). Symbols are allocated either in the heap or in opcache SHM, so we only copy the hashtables, not the symbols themselves.

Restoring

When restoring, we just restore chunk copies to their old location, and add the old chunks back to the heap. We then restore the symbol tables.

for (chunk, copy) in copies:
    memcpy(chunk, copy, MM_CHUNK_SIZE)
    heap.chunks[] = chunk

Thoughts

Snapshots are private to each php instance, as the location of the heap is specific to each instance (this is important because when we restore a snapshot, we want to do so at the original memory location).

Sharing snapshots is possible if a fixed memory region is reserved in the parent process, like the opcache SHM. But this wouldn't work for ZTS, as each php instance needs separate regions anyway. Also, instance-private snapshots are convenient to support snapshotting of internal objects (see above).

One issue with raw-copying heap chunks is that some slots will be reported as leaks after a restore, in debug builds, but this is fixable.

A less brute-force approach would copy/relocate every individual zval/object/etc to a new heap separately, in a similar fashion as zend_persist.c. CoW objects such as arrays and strings could be moved to the native heap, to reduce restoring costs further. It would result in a smaller heap (reduces restoring cost). However, relocating would increase maintenance, as every internal object needs to know how to clone itself to a new location.

Performance

Benchmark

• Request /en/blog/ on the Symfony Demo app
• With Nginx+PHP-FPM vs FrankenPHP
• 100 concurrent requests
• nprocs*2 threads/processes

Results

PHP-FPM with snapshotting is slower than FrankenPHP. How much slower depends on the snapshot size and of when it's taken. Best results were obtained when taking a snapshot just after the first request:

Request duration (95 percentile; lower is better)
base:       87.090000; +0.00%
snapshot:   75.020000; -13.86%
frankenphp: 71.280000; -18.15%

Requests per second (higher is better)
base:       1420.509395; +0.00%
snapshot:   1655.731823; +16.56%
frankenphp: 1698.379295; +19.56%

Restoring the state takes about 14% of the time in this benchmark. This could possibly be reduced by a few percent.

Taking the snapshot just after booting the kernel has smaller improvements compared to baseline:

Request duration (95 percentile; lower is better)
base:       86.830000; +0.00%
snapshot:   84.630000; -2.53%
frankenphp: 71.620000; -17.52%

Requests per second (higher is better)
base:       1420.183333; +0.00%
snapshot:   1472.085336; +3.65%
frankenphp: 1695.029720; +19.35%

Initializing all container services before snapshot is slower than baseline due to the cost of restoring state.

More benchmarking / analysis is needed.