Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125832
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 23 Oct 2024 10:43:59 +0100
Message-ID: <CAMhsXHy=FLtGWEdvtiS9zD3rTP0SOL=A0=i=606W3o8ArLQzkA@mail.gmail.com>
Subject: [PHP-DEV] RFC: Support Read-Only opcache.file_cache for use with Docker
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: sam@melroseandco.uk (Samuel Melrose)

Hello,

Following on from a chat with some very helpful contributors on GitHub
(https://github.com/php/php-src/issues/16484), I'd like to request
feedback on a change and potentially put it forward as an RFC please.

Change Description:

The `opcache.file_cache` folder must currently be writable, but I
propose a read-only mode (potentially enabled via
`opcache.file_cache_read_only=3D1`) that allows the folder to be used
for loading files when it isn't writable.

`opcache.file_cache_read_only=3D1` will fail unless
`opcache.validate_timestamps=3D0` and `opcache.revalidate_freq=3D0`,
indicating the code is intended to be read-only.

An example PR to achieve this is here:
https://github.com/php/php-src/pull/16551 (I'd love some feedback
please!).

Why?:

When building containers (i.e. Docker) that contain both the PHP
runtime and application code (that isn=E2=80=99t going to change once built
into the container), a lot of CPU cycles are wasted re-warming the
opcache every time an instance of the container starts, even though
the code will always remain the same.

In a large distributed container based platform like Lambda, App
Runner, App Engine or Cloud Run, there are significant performance
gains & cost savings to be realised by being able to pre-warm the JIT
at container build time (i.e. in the CI/CD pipeline), then load it
from disk at container startup.

It is fairly common on these large container platforms for the entire
file-system to be read-only (e.g. Kubernetes `readOnlyRootFilesystem`)
as a security hardening measure, which makes using the existing
`opcache.file_cache` impossible.

Usage:

The intended usage for this change is to build the opcache via the CLI
in the CI/CD workflow, with something like this:

`@php -dopcache.enable_cli=3Dtrue -dopcache.file_cache=3D$(pwd)/opcache
-dopcache.file_cache_only=3Dtrue prewarm.php`

```php
<?php

/**
 * Composer autoloader...
 */

$filesToLoad =3D require __DIR__ . '/vendor/composer/autoload_files.php';

// Prevent composer autoloading files...
foreach ($filesToLoad as $fileIdentifier =3D> $file) {
    $GLOBALS['__composer_autoload_files'][$fileIdentifier] =3D true;
}

require __DIR__ . '/vendor/autoload.php';

$finder =3D (new Symfony\Component\Finder\Finder())
    ->files()
    ->name('/\.php$/')
    ->ignoreDotFiles(false)
    ->ignoreVCSIgnored(false)
    ->exclude([
        'vendor/composer',
    ])
    ->notPath([
        'fuel/core/bootstrap.php',
        'fuel/core/vendor/htmlawed/htmlawed.php',
    ])
    ->in(__DIR__);

foreach($finder as $file) {
    $filepath =3D $file->getRealPath();
    echo "Compiling file " . $file->getRelativePathname() . " ... " .
        (
            opcache_is_script_cached($filepath) ?
                'EXISTS' : (
                    opcache_compile_file($filepath) ? 'OK' : 'FAIL'
                )
        ) .
        "\n";
}
```

Then including the `opcache` folder, along with the application code,
and the following values in `php.ini` inside the Docker container
build:

```
; Tune opcache
opcache.revalidate_freq=3D0
...other values...
## this below should be true on production
opcache.enable_file_override=3Dtrue
## this below should be false on production
opcache.validate_timestamps=3Dfalse

; Enable pre-warmed opcache
opcache.file_cache=3D/workspace/opcache
opcache.file_cache_read_only=3Dtrue
opcache.file_cache_consistency_checks=3Dfalse
```

Considerations:

Part of the opcache file path when stored on disk is the
`zend_system_id`, which from my testing, only stays the same on the
exact same build of PHP (and as a result this means if your service is
restarting to install a PHP update, the opcache files are no longer
valid anyway, but not necessarily a problem with Docker containers
that stay static until updated as a whole).

Benchmarks:

First request without opcache warm'd:

```
$ curl -w "@curl-format.txt" -o /dev/null -s http://localhost:32768/_ah/war=
mup
     time_namelookup:  0.000032s
        time_connect:  0.000160s
     time_appconnect:  0.000000s
    time_pretransfer:  0.000193s
       time_redirect:  0.000000s
  time_starttransfer:  0.221376s
                     ----------
          time_total:  0.221478s
```

First request with opcache pre-warm'd:

```
$ curl -w "@curl-format.txt" -o /dev/null -s http://localhost:32768/_ah/war=
mup
     time_namelookup:  0.000029s
        time_connect:  0.000164s
     time_appconnect:  0.000000s
    time_pretransfer:  0.000198s
       time_redirect:  0.000000s
  time_starttransfer:  0.053059s
                     ----------
          time_total:  0.053171s
```

The CPU on the machine I'm testing from is a lot more powerful than
the CPU allocation for containers in production (it's lots of small
instances that scale horizontally), so I'm expecting the improvement
to be even more dramatic there.

Struggling to benchmark that properly though, as prod/pre-prod for
serverless all has a read-only root FS.

** What does everyone think? Feedback welcome please. **