Skip to content

atrope/bref-bootstrap-benchmarks

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

36 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

This is a benchmark of possible solutions for Bref to run PHP on AWS Lambda.

The issue in Bref is here: mnapoli/bref#100.

I will use Symfony in the examples just for illustration but this applies to all frameworks. Jump at the end for the numbers.

Solutions

Solution A

We run the PHP code in the same process as bootstrap, very similarly to what can be done with ReactPHP/Amp/Aerys/Swoole...

This is very fast, both for cold starts and warm requests! We can get response times below 10ms with that. However, just like when using such frameworks outside of lambda we have disadvantages: the memory is shared between all requests. That means we can have memory leaks, we have to be careful about global state, etc. Also a fatal error will kill the whole lambda (a new lambda will be started by AWS but that means a new cold start).

This is a very interesting option that can be worth proposing as an option, but it cannot be the default solution that will work with all apps/frameworks.

Click here for code examples

Example of a bootstrap:

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

// BOOT Symfony BEFORE a request comes in!
$kernel = new Kernel('prod', false);
$kernel->boot();
$symfonyAdapter = new SymfonyAdapter($kernel);

while (true) {
    $event = waitForEventFromLambdaApi(); // This is a blocking HTTP call until an event is available

    $request = RequestFactory::fromLambdaEvent($event);
    // REUSE the same Symfony Kernel, meaning fast response time!
    $response = $symfonyAdapter->handle($request);
    $lambdaResponse = LambdaResponse::fromPsr7Response($response);

    signalSuccessToLambdaApi($lambdaResponse);
}

Solution B

The bootstrap starts a sub-process (exec) every time an event needs to be processed.

That allows to protect the bootstrap process from failures of the children. This is basically what Bref does at the moment.

This is similar too to how PHP-FPM works (in the spirit at least).

Click here for code examples

Example of a bootstrap:

<?php
// ...
while (true) {
    $event = waitForEventFromLambdaApi(); // This is a blocking HTTP call until an event is available

    $process = new Process(['/opt/bin/php', 'index.php', /* pass the event as an argument */]);
    $process->run(); // This waits for the process to finish

    // [fetch response ...]

    signalSuccessToLambdaApi($lambdaResponse);
}

Example of a index.php that could be executed by that:

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

// [fetch event from process args]

$kernel = new Kernel('prod', false);
$kernel->boot();
$symfonyAdapter = new SymfonyAdapter($kernel);
$request = RequestFactory::fromLambdaEvent($event);
$response = $symfonyAdapter->handle($request);
$lambdaResponse = LambdaResponse::fromPsr7Response($response);

// [return response to bootstrap somehow]

exit(0); // DIE!

Solution C

Just like B except bootstrap does not handle events: it immediately executes a sub-process. The PHP sub-process will call the integration HTTP API and wait for an event. That means that we can run code before waiting for an event. E.g. we can bootstrap Composer's autoloader and Symfony before a request comes in!

Click here for code examples

Example of a bootstrap:

<?php
// ...
while (true) {
    $process = new Process(['/opt/bin/php', 'index.php']);
    $process->run(); // This waits for the process to finish (i.e. waits until an event has been processed)
}

Example of a index.php that could be executed by that:

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

// BOOT Symfony BEFORE a request comes in!
$kernel = new Kernel('prod', false);
$kernel->boot();
$symfonyAdapter = new SymfonyAdapter($kernel);

$event = waitForEventFromLambdaApi(); // This is a blocking HTTP call until an event is available

$request = RequestFactory::fromLambdaEvent($event);
$response = $symfonyAdapter->handle($request);
$lambdaResponse = LambdaResponse::fromPsr7Response($response);

signalSuccessToLambdaApi($lambdaResponse);

exit(0); // DIE!

Solution D

How about instead of creating a new process we fork the bootstrap process? The app would bootstrap once in total, but still there is no shared state between events (because each event is processed by a fork).

Click here for code examples

Example of bootstrap:

<?php
// ...
require __DIR__ . '/vendor/autoload.php';
// BOOT Symfony ONLY ONCE for all the requests!
$kernel = new Kernel('prod', false);
$kernel->boot();
$symfonyAdapter = new SymfonyAdapter($kernel);

while (true) {
    $pid = pcntl_fork();
    if ($pid) { // Root process
        pcntl_wait($status); // Wait for the child to process the event
    } else {    // Child process
        // Here the autoloader is already loaded and Symfony initialized!
        $event = waitForEventFromLambdaApi(); // This is a blocking HTTP call until an event is available

        $request = RequestFactory::fromLambdaEvent($event);
        $response = $symfonyAdapter->handle($request);
        $lambdaResponse = LambdaResponse::fromPsr7Response($response);

        signalSuccessToLambdaApi($lambdaResponse);

        exit(0); // The fork DIES! The root process will resume its execution and loop
    }
}

Solution E

Solution E is about starting PHP-CGI/PHP-FPM and run it with only one PHP worker. The bootstrap would be responsible for forwarding Lambda events using the FastCGI protocol.

Solution F

Solution F is about starting the PHP built-in webserver. The bootstrap would be responsible for forwarding Lambda events to the webserver via HTTP.

Solution G

Solution G is about writing a custom PHP SAPI (in C) that is inspired from PHP-FPM and the built-in webserver. This SAPI would run as bootstrap, start and wait for an event.

When an event is available it would execute the target PHP script (e.g. index.php) and when the script finishes it would reset the process to scratch and reuse the same process (like PHP-FPM). That would avoid the cost associated to creating a new process (or forking).

That could also allow to run a boot script before an event comes, e.g. load Composer and boot Symfony before a request comes.

Results

Those are Lambda execution time (not HTTP response time because you would have to account API Gateway).

Solution Framework Average Minimum URL
LAMP stack PHP 1ms 0ms
LAMP stack Symfony 6ms 4ms
Bref 0.2 (baseline) PHP 23ms 15ms url
Bref 0.2 (baseline) Symfony 50ms 26ms url
A PHP 5ms 1ms url
A Symfony 6ms 3ms url
B
C PHP bugged - please help :)
C Symfony 81ms 65ms url
D PHP 12ms 6ms url
D Symfony 26ms 15ms url
E PHP 5ms 1.1ms
E Symfony 27ms 14ms
F PHP 5ms 1.6ms
F Symfony 24ms 16ms
G

The LAMP stack is a baseline of running the same code but on a classic server with Apache or Nginx. This will help compare performances between LAMP and PHP on Lambda.

How to run

  • clone the repository
  • make install
  • go into a subdirectory and run make preview to test it locally (you'll need to install AWS SAM, the lambda will run in Docker automatically, try it out it's magic!)
  • run make deploy in a subdirectory to deploy that lambda

To deploy you will need to create a bucket and update the bucket name everywhere in the scripts. I also used the us-east-2 region because I don't have anything in that region so it's easy to delete everything afterwards. If you want to let that be configured by an env variable or some other config file send a pull request!

To benchmark: run ab -c 1 -n 100 <the url of the lambda> (check the URL responds correctly). Check out the execution time of the lambda in Cloudwatch.

The first time you deploy, if it fails, you will need to delete the stack in CloudFormation manually. This is how CloudFormation works.

About

Benchmark of possible solutions for Bref and the new AWS Lambda runtime API

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • PHP 65.9%
  • HTML 28.3%
  • Makefile 5.8%