mnapoli / bref-bootstrap-benchmarks Goto Github PK

We're measuring performance, which is interesting obviously, but perhaps we should also look at the (additional) bootstrap time.

Eg. the php webserver has a sleep of 1 sec, which can be significant if it's run not so often.
I'm not sure what realistic numbers are in the percentage of cold starts, but should we take them into account?

We could benchmark them using a fresh deploy with a higher concurrency, right?

So something like ab -c 100 -n 100 https://.. would spawn 100 fresh workers (after a new deploy), right?

When I'm calling opcache_get_status() I get: Call to undefined function opcache_get_status(). When checking phpinfo() it shows that opcache is enabled in the compilation, but did you also include the opcache.so extension? And it should be enabled + enabled for cli + validate timestamps should be disabled.

I thought that the duration of a lambda was the time spend between these events:

• the lambda asks for an event to process (via the HTTP runtime API)
• the lambda sends a response for the event (via the API again)

From what I've seen in some tests the duration is actually between:

• the lambda asks for an event to process
• the lambda asks for the next event to process

It doesn't matter if we return a response early and keep processing things. It also doesn't matter if we pre-load stuff before a request comes in, because this is actually time spent in the previous lambda execution…

With that in mind, solution C doesn't actually save any time by booting Symfony and then waiting for an event.

I'm not sure though that C should be removed/marked as obsolete as I believe it can still be faster than B (there is not the overhead of passing the event via CLI parameters). However I think opcache is not enabled in C so current results are not up to date (I'll open a separate issue for that).

Solution E currently states that it would be forwarding Lambda events to PHP-FPM via FastCGI. I wrote a nodejs shim last summer that is similar. However, it simply forwards directly to php-cgi are you looking for something similar to this nodejs code or is Solution E really about trying to leverage PHP-FPM?

/*jslint node: true */

const spawn = require("child_process").spawnSync;
const parser = require("http-string-parser");
var path = require("path");

exports.handler = function(event, context) {
    // Sets some sane defaults here so that this function doesn't fail
    // when it's not handling a HTTP request from API Gateway.
    var requestMethod = event.httpMethod || 'GET';
    var requestBody = event.body || '';
    var serverName = event.headers ? event.headers.Host : 'lambda_test.dev';
    var requestUri = event.path || '';
    var headers = {};
    var queryParams = '';

    // Convert all headers passed by API Gateway into the correct format for PHP CGI.
    // This means converting a header such as "X-Test" into "HTTP_X-TEST".
    if (event.headers) {
        Object.keys(event.headers).map(function (key) {
            headers['HTTP_' + key.toUpperCase().replace(/-/g, '_')] = event.headers[key];
            headers[key.toUpperCase().replace(/-/g, '_')] = event.headers[key];
        });
    }

    // Convert query parameters passed by API Gateway into the correct format for PHP CGI.
    if (event.queryStringParameters) {
        var parameters = Object.keys(event.queryStringParameters).map(function(key) {
            var obj = key + "=" + event.queryStringParameters[key];
            return obj;
        });
        queryParams = parameters.join("&");
    }

    // Spawn the PHP CGI process with a bunch of environment variables that describe the request.
    var scriptPath = path.resolve(__dirname + '/../../public/index.php')

    var php = spawn('php-cgi', ['-f', scriptPath], {
        env: Object.assign({
            REDIRECT_STATUS: 200,
            REQUEST_METHOD: requestMethod,
            SCRIPT_FILENAME: scriptPath,
            SCRIPT_NAME: '/index.php',
            PATH_INFO: '/',
            SERVER_NAME: serverName,
            SERVER_PROTOCOL: 'HTTP/1.1',
            REQUEST_URI: requestUri,
            QUERY_STRING: queryParams,
            AWS_LAMBDA: true,
            CONTENT_LENGTH: Buffer.byteLength(requestBody, 'utf-8')
        }, headers, process.env),
        input: requestBody
    });

    // When the process exists, we should have a compvare HTTP response to send back to API Gateway.
    var parsedResponse = parser.parseResponse(php.stdout.toString('utf-8'));

    // Signals the end of the Lambda function, and passes the provided object back to API Gateway.
    context.succeed({
        statusCode: parsedResponse.statusCode || 200,
        headers: parsedResponse.headers,
        body: parsedResponse.body
    });
};

Currently the Twig cache is disabled in the Symfony test. This doesn't allow to compare with actual Symfony performances outside of AWS Lambda, this should be fixed.

The php.ini is not provided here.

I think what would be great is compile PHP so that php.ini is automatically loaded, rather than having to provide it explicitly every time. It would also prevent any mistake in PHP scripts running sub-processes.

Hi,
Sometimes when we make a request the requests fails with a 502.

The Log show us that

Fatal error: Uncaught ErrorException: stream_socket_client(): unable to connect to unix:///tmp/php-fpm.sock (Connection refused) in /opt/vendor/hollodotme/fast-cgi-client/src/Socket.php:183
Stack trace:
#0 /opt/vendor/hollodotme/fast-cgi-client/src/Socket.php(191): hollodotme\FastCGI\Socket->handleFailedResource(111, 'Connection refu...')
#1 /opt/vendor/hollodotme/fast-cgi-client/src/Socket.php(162): hollodotme\FastCGI\Socket->connect()
#2 /opt/vendor/hollodotme/fast-cgi-client/src/Client.php(105): hollodotme\FastCGI\Socket->sendRequest(Object(class@anonymous))
#3 /opt/vendor/hollodotme/fast-cgi-client/src/Client.php(77): hollodotme\FastCGI\Client->sendAsyncRequest(Object(class@anonymous))
#4 /opt/bootstrap(161): hollodotme\FastCGI\Client->sendRequest(Object(class@anonymous))
#5 /opt/bootstrap(225): sendToApp('/v2/cd/32', Array, Object(hollodotme\FastCGI\Client))
#6 {main}

Next hollodotme\FastCGI\Exceptions\ConnectException: Unable to connect to FastCGI application: Connection refused in /opt/vendor/hollodotme/fast-cgi-c in /opt/vendor/hollodotme/fast-cgi-client/src/Socket.php on line 226

This Happens in Solutions E and H

I Will try to debug more and see if I can fix this problem