Evaluate webserver integration

[abertschi]

PHP SAPI: https://github.com/php/php-src/tree/master/sapi

[avierr]

Probably, we must leave this to the user level PHP scripts that implement SAPI or run as an Async server like https://www.swoole.co.uk/ or https://reactphp.org/

[abertschi]

There are many exciting things to work on in this issue.

Some ideas:

• use native-image to compile graalphp to native code and then access it without a full JVM from C. This could then be used in an Apache Module similar to mod_php to communicate with the interpreter. We already have a compiling native-image build.
• evaluate how efficient an implementation is which follows the FastCGI protocol and integrate it into a popular websever (apache, nginx, ...)
• these approaches have the advantage to source out the web stack to existing web servers.

https://stackoverflow.com/a/2772929 https://en.m.wikipedia.org/wiki/FastCGI https://news.ycombinator.com/item?id=24683304

[abertschi]

It is easier to see how an event driven approach like the links you posted above can benefit from GraalVM's dynamic compiler because the event loop is modeled within PHP. One has to figure out how an approach with a mod_php like module or a fastCGI implementation can benefit from dynamic compilation. Graalphp's context must persist across requests to gather enough profiling feedback for dynamic compilation.

[avierr]

from a business perspective, people prefer PHP-FPM more than mod_php

Reasons:

• A lot easier to install and configure
• A run-time issue in PHP-FPM does not take down the server
• You can switch PHP versions at runtime. This is great for webhosts who want to give users a choice to choose their PHP version.
• You can add new versions of PHP without restarting the web-server.
• You can replace an existing PHP version with a new security patch version without a webserver restart.

To note: PHP supports a feature called preloading: https://www.php.net/manual/en/opcache.preloading.php

[avierr]

People are moving to Swoole and other implementations, cos classical PHP-FPM doesn't scale well when compared to other technologies like NodeJS

Swoole solves this by going async, but this introduces very ugly async code and you can't do anything other than plain IO, and as expected, any kind of image manipulation or simple CPU intensive task will block the entire event loop. You have to be a lot more careful when writing Async code.

The majority of the applications use classic PHP-FPM, and there is no real-world performance benefit even with the introduction of PHP-8-JIT, because the classical FPM is single-threaded and spawns child processes based on max child processes that you configure. A single FPM process will block as long as it finishes with the entire request.

This is one area, which we could improve on and deliver some real-world performance improvements,

1. Bring in threads
2. possibly Allow switching to virtual threads in the future, to allow for better scheduling (https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html). this is not a pre-emptive scheduler, so we will still need multiple graalphp-fpm processes.