symfony-bridge
symfony-bridge copied to clipboard
How to use with a custom runtime (that also extends SymfonyRuntime)
I have a custom runtime that is like this
<?php
declare(strict_types=1);
namespace App\Runtime;
use App\Config\KmsDotEnvLoader;
use Symfony\Component\Dotenv\Dotenv;
use Symfony\Component\Runtime\SymfonyRuntime;
class SymfonyWithKMSRuntime extends SymfonyRuntime
{
/**
* {@inheritdoc}
*
* @param array<mixed> $options
*/
public function __construct(array $options = [])
{
parent::__construct($options);
$kmsDotEnvLoader = new KmsDotEnvLoader(new Dotenv());
$kmsDotEnvLoader->inject(\dirname(__DIR__).'/../'.KmsDotEnvLoader::ENCRYPTED_FILE);
}
}
i.e it reads additional env variables from a kms-encrypted file
however if i try to use the version 0.2.0 wihtout php-fpm, it fails because the BrefRuntime is hardcoded.
Is there a way to do what I want with the bref/symfony-bridge as it is ? (i.e to get the env variables set-up, I don't mind not using 'my' runtime, as long as the job is done)
I got it working by moving this piece of code in the constructor of my kernel, but it degrades a lot the performance ( I think because now it needs to read the configuration at every request and not only cold ones ? )
WIth my PR linked above, I got it working without needing to change anything but performance are still way worse
i.e around 100ms for a /ping route vs ~17ms before with php-fpm layer , am I doing something wrong ?
Are you using BREF_LOOP_MAX
to keep the kernel alive between requests (with the "function" layer)?
If not, then each request will be handled by a new process.
If you do, then running the code in the kernel's constructor should have the same result as using a custom runtime.
ah i thought BREF_LOOP_MAX was "unlimited" by default, and putting a number was to force-reboot to avoid memory leak, I will try that then ! (to be honest the doc was not clear about this parameter :angel: )
Ah interesting, if we could make that clearer in the README that might be better indeed.
indeed with BREF_LOOP_MAX it works now, and OMG , my /ping was before 10ms -> now 2ms , my /dashboard was 140ms -> now 40ms !!
by the way, do you know if now , with this method if the events that are done on a ec2 after fastcgi_finish_request
are now also done after the response is sent ? because I use to have a server-side analytics that was slow on lambda because of the synchronous nature of labmda, and now it seems to not be the case anymore
(which would explain the 140 -> 40ms , as this after-response alone was taking 50ms )
The terminate event should still run synchronously (unless there were some amazing changes in Lambda). Maybe it runs much faster now for different reasons?
ok, i will try to add some log, because it seems that unfortunately it does not work anymore with blackfire ^^ (or at least not with the CLI / plugin extensions ^^)