[PHP, Spiral/RoadRunner]: update Dockerfile to address RR v2024.x.x requirements

[rustatian]

Starting from the RR v2024.1.0 it requires protobuf and grpc extension installed. They used to improve the performance of parsing proto-requests.

[joanhey]

Help me with laravel and symfony with roadrunner.
I spend almost 1 week with Symfony runtime and roadrunner !!

Thank you !!

[rustatian]

Hey @joanhey 👋

Have you tried this: https://github.com/php-runtime/roadrunner-symfony-nyholm ?

[joanhey]

Symfony with Roadrunner
https://github.com/joanhey/FrameworkBenchmarks/actions/runs/9093103519/job/24991316667#step:9:1757

Files:
joanhey@19554eb

@rustatian Perhaps it's easy for you fix it !!

[rustatian]

Ah, got u (I'm not a PHP dev btw, but I'll try to help you). You need to install the latest versions of the spiral/worker and spiral/roadrunner-http packages: https://docs.roadrunner.dev/general/compatibility#compatibility-with-roadrunner-php-packages

[joanhey]

The php-runtime only use "spiral/roadrunner": "^2.0", so they need to fix it to work with rr v2024.
https://github.com/php-runtime/roadrunner-symfony-nyholm/blob/main/composer.json#L15C9-L15C37

For now working using RoadRunner v2023.3. #9024

Thank you @rustatian

[rustatian]

You're welcome @joanhey 😃
I'll ask our PHP team to create a PR to fix RR support for the symfony runtime component.

[joanhey]

This PR was merged without the tests and fail.
I'll fix it and clean the dockderfile.

[rustatian]

Thanks @joanhey 👍 , feel free to ping me if you need any help with RR. I already asked our PHP team to send a PR to the symfony runtime, let's see how it goes 😃

[joanhey]

Ping me when the symfony runtime is updated.

[joanhey]

I'll enable JIT also.

[joanhey]

Now build the grpc but still fail the tests.
https://github.com/TechEmpower/FrameworkBenchmarks/actions/runs/9118638074/job/25072218311?pr=9032

[rustatian]

I've double checked, grpc ext can be excluded. Only protobuf is really required.

[rustatian]

I can push a PR to exclude it

[joanhey]

I'm changing more things in #9032
By default the php:8.3-cli don't include OPCache.

[joanhey]

Without grpc the container is built in ~3 min, before ~12 min.

[joanhey]

Still fail the update test. It was failing for a lot of time also.
I think that it is a problem with the ORM and cache.
I can help, but your team need to check it.

[joanhey]

Well they need to check also, why it create so many db calls .

The update problem:

[rustatian]

This is strange... You mean, that after adding the protobuf extension, tests start to fail?

[joanhey]

NO.
The update test was failing before in all the runs. Before the tests didn't watch the rows changed in the db.
https://tfb-status.techempower.com/results/662d8347-d314-4010-857e-fee18302b327

https://tfb-status.techempower.com/unzip/results.2024-05-07-03-20-53-233.zip/results/20240501071818/spiral/update/verification.txt

And the excessive db calls also exist before:
https://tfb-status.techempower.com/unzip/results.2024-05-07-03-20-53-233.zip/results/20240501071818/spiral/db/verification.txt

EDIT: both problems are from the ORM.

[rustatian]

Ok, this is some problem in Spiral Framework, right?

EDIT: ORM, ok, got u. Will send these results to our PHP team.

[joanhey]

The problems are from the ORM.

[joanhey]

Your PHP team can contact me, if they need it.

[joanhey]

Today I send a private message in Slack to Dunglas for the very bad results of FrankenPHP with laravel.
Only 200 req/s 😞 , and asked him to check the PR, still waiting for a response. But for me the PR is correct.

[rustatian]

Oh, 200req/s is a very bad result. Hope he'll find the reason.

[joanhey]

Just checked the changes in the new PR.
And OPCache and JIT are enabled for Spiral.

[joanhey]

But after very reloads, still show:
Cache hits => 0
So for any reason it isn't using the OPCache.

[joanhey]

If you open a new PHP-CLI each time for each child.
The OPCache never will be reused !!

[rustatian]

OPCache will be used per CLI process, since it is an SHM region related to a current PHP process. In FPM for example, in a fork (not TSRM) mode, they share single SHM region for all workers (since FPM fork the ptr to it). Thus they can benefit from that.
But RR still benefit from OPCache, but in the other ways.
Also, on Windows (for example), all PHP CLI processes can share the singe SHM region.

[joanhey]

Actually it isn't using the opcache, only generate the opcodes but are never reused.
Test yourself, and the hits show always 0.

[joanhey]

I'll try later with only 1 worker.

EDIT: tested with 1 worker, always Cache hits => 0

[rustatian]

You need to enable opcache cli option.

[joanhey]

It's enabled

EDIT: with 1 woker only, to avoid workers without initialization

[rustatian]

You may try to use opcache.cli directive directly in the server.command. However, it is correct, that applications like RR benefit minimal from OPCache, since everything already in memory.
Unlike FPM, we don't need to use request_startup/shutdown (RINIT) on every request, unloading the script entirely.

[rustatian]

Or you may add opcache.enable_cli=1 to your php.ini. Based on your PR, I see only JIT related option enabled.

[joanhey]

I understand persistent php, and still benefit a lot of the OPCache.
But RR is the contrary use the time to create the opcodes, but never reuse it.
It's enabled in the php.ini, and the screen capture is from the Spiral running in local.

./tfb --mode debug --test spiral

I'll try to add in the server.command. But I think that will have the same effect.

[joanhey]

Show the info() method that I added in local to the controller.