HTTP layer without PHP-FPM

[kwn]

Hi @mnapoli

Due to instability of php-fpm layer I encountered and described here: #316

I started wondering why does Bref actually needs a real php-fpm process? Would it be possible to use the PHP functions layer and set up superglobal variables based on the event that comes from lambda? Or better - create PSR-7 compatible request based on the event, execute the request handling in a framework and return the response? Are there any pitfalls with that approach? Did you try it out? I saw bref performance summary where you some possible options of running http compatible layer, but AFAIR the above approach wasn't described there.

In a similar manner it's very common to run an instance of your application when you run e.g. symfony WebTestCase tests. You don't need any real php-fpm / http processing. Just a client that is capable to set up an environment.

[GromNaN]

That looks like the scenario A presented here: #100 (comment)

It might be possible with the PHP functions runtime. https://bref.sh/docs/runtimes/function.html
Edit : the bootstrap actually call the script with php-cli.

[wolfy-j]

We have tested PHP inside lambda function in daemon mode (without php-fpm), the performance per endpoint was close to 0.2ms per task (no overhead on bootload). But daemonizing is a bit different topic.

[jaikdean]

We're using this approach in a Symfony app running on a custom Serverless-based runtime (not using Bref). We build Symfony request objects from API Gateway Lambda events and pass them into the kernel.

It works well, the main issue we ran into was HTTP sessions. Basically, you need to implement your own session system and not use any of the built-in session functions, as they're built around a single session per process.

We also instantiate and destroy the kernel once per request as there were problems with Doctrine entities and a few other bits using a single kernel to handle multiple requests.

[nealio82]

FTR we also ran into the Symfony session issue with Bref 0.2. From what I recall we found that Symfony was letting PHP create the set-cookie: PHPSESSID header itself rather than managing and returning it within the framework. We addressed it in these PRs: https://github.com/mnapoli/bref/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+session

@kwn do you still have the same problems with the fpm layer after the latest release (0.3.9). We switched out the fastcgi-client library for something else...

[mnapoli]

Regarding the original topic (running HTTP apps without PHP-FPM) there are a few options:

1. booting a new PHP process for each request (overhead of the new process but complete isolation)
2. running a single process that handles all the requests (no overhead, great perfs, but shared memory so watch out for memory leaks) -> this is similar to ReactPHP

Turns out solution 1 is what we did in Bref 0.2: https://github.com/mnapoli/bref/tree/0.2.37#http-applications This older Bref version contains what's needed to turn a API Gateway event into a PSR-7 request (and same for the response).

I plan on reintroducing that in the future (will require some effort to bring it up to date with all the fixes and improvements that have happened since then), mainly for the performance improvements that solution 2 can bring.

For those interested you can find benchmarks of those different solutions here: https://github.com/mnapoli/bref-bootstrap-benchmarks#solution-a

[mnapoli]

This has been implemented in the latest release!

[kwn]

Amazing!!