Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a first attempt for a readme #28

Merged
merged 1 commit into from
May 4, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 79 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,9 +12,87 @@ composer req bref/symfony-bridge

## Usage

Update your Kernel.php
You only need to one one small change To quickly setup Symfony to work with Bref.

```diff
// src/Kernel.php

namespace App;

use App\Repository\Test\TestRepository;
+ Bref\SymfonyBridge\BrefKernel;
use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait;
use Symfony\Component\Config\Loader\LoaderInterface;
use Symfony\Component\Config\Resource\FileResource;
use Symfony\Component\DependencyInjection\ContainerBuilder;
-use Symfony\Component\HttpKernel\Kernel as BaseKernel;
use Symfony\Component\Routing\RouteCollectionBuilder;

- class Kernel extends BaseKernel
+ class Kernel extends BrefKernel
{
// ...
```

Now you are up and running.

## Optimize first request

The first HTTP request that hits your application after you deployed a new version
will use a cold cache directory. Symfony now spends time building thc cache. It may
take everything between 1-20 seconds depending on the complexity of the application.

Technically this happens whenever your application run on a new Lambda. That could
be when you get a lot more traffic so AWS increases the resources or when AWS just
decides to kill the lambda function (or server) that you are currently on. It is
normal that this happens at least a handful of times every day.

To optimize the first request, one must deploy the application with a warm cache.
In a simple application it means that the deploy script should include `cache:warmup`
to look something like this:

```bash
# Install dependencies
composer install --classmap-authoritative --no-dev --no-scripts

# Warmup the cache
bin/console cache:warmup --env=prod

# Disable use of Dotenv component
echo "<?php return [];" > .env.local.php
Nyholm marked this conversation as resolved.
Show resolved Hide resolved

serverless deploy
```

## Optimize cache

When running Symfony on Lambda you should avoid writing to the filesystem. If
you prewarm the cache before deploy you are mostly fine. But you should also make
sure you never write to a filesystem cache like `cache.system` or use a pool like:

```yaml
framework:
cache:
pools:
my_pool:
adapter: cache.adapter.filesystem
```

If you dont write to such cache pool you can optimize your setup by not copy the
`var/cache/pools` directory. The change below will make sure to symlink the `pools`
directory.

```diff
// src/Kernel.php


class Kernel extends BrefKernel
{
// ...

+ protected function getWritableCacheDirectories(): array
+ {
+ return [];
+ }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with that is that you'll get write errors while using any of the symfony components that don't completely warm. If you don't log warnings that you won't notice... maybe it isn't important.

I addressed that here: #21 (comment)
and later remarked that it is more performant to not warm the pools directory at all and rather redirect the cache to a cold tmp folder: #21 (comment)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, But I thought I did explain that you need to warm the cache before deployment. If you do, this is safe, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of. The pools cache.system (which writes to pools) is not completly warmed. Some symfony components will have a cold cache and will try to write and fail.

This will result in a warnings that you could ignore, they aren't fatal. But i'm not sure I would recommend such a setup.

Copy link
Collaborator Author

@Nyholm Nyholm Apr 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds like that application has a suboptimal cache warming strategy. These warnings should be visible in Cloudwatch, right?

This is how I will run my applications for maximum performance. But it is optional (and not default), maybe this settings is not for everybody.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And to the safe aspect: The pools directory is always optional. It can be completely empty and you application would work.

I can't really say which of these 3 scenarios is the best and should be recommended:

  • not copying the pools folder and having all system pool writes silently fail (which happens even with warmed cache since not all caches are fully warmed). This isn't too bad as those entries are quickly generated but I'd like to somehow prevent the log spam here without suppressing all cache warnings.
  • copying the pools folder (which takes time) but with the advantage that future request will be able to write
  • not deploying the pools folder at all and reconfiguring it to /tmp/pools = this was my final result in Symfony's capability to run on read-only out of the box #21 for being the easierst to setup... it doesn't even require the BrefKernel to work. And the overhead of having the pools folder cold is fairly small.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your second scenario is the best default (as it currently is) and your first scenario is for optimal performance (what this PR is making a comment about).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats the problem, we both "think" but we don't have hard evidence 😉
In 1 case your are right, option 2 is definitely the fastest if you optimizing for cold starts which is probably a good idea.

Copy link
Contributor

@Nemo64 Nemo64 Apr 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add that it will generate warnings in your log like the ones described in symfony/symfony#29357 so that someone using that approach knows that this downside exists.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats the problem, we both "think" but we don't have hard evidence

That is not true =)

In #18 I showed that symlinking in faster that copying. And symfony don't write to filesystem unless you doing filesystem caching. (docs).

We also already discussed that copying pools is a good default.

In 1 case your are right, option 2 is definitely the fastest if you optimizing for cold starts which is probably a good idea.

Yes, That is why I've documented exactly that.

The readme may not be complete after this PR but it is a good start and nothing in the PR is wrong. I would be happy to see contributions with more content, different deploy strategies or PRs with more logging. But that is all out of scope for this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, I think I suffer from the same confusion here: I thought we decided on a different implementation.

Let's collect all the data we have and compare it. I have opened #31 for that. I'll be honest: we discussed so many things, with so many benchmark results, that I have trouble to keep track. Maybe you too ^^

}
```