New Laravel configuration is significantly slower

1

Recently the default configuration for Laravel has changed, see: Laravel docker improvements by fideloper · Pull Request #1143 · superfly/flyctl · GitHub

I like it, it’s much simpler. Except the performance of this new config is significantly worse, especially bootstrapping. Bootstrapping now takes > 100ms, with a total response time of sometimes up to 200ms even for simple requests. When I switch to the old Docker configuration, my total response times go down to ~60ms.

Any idea how I can fix that? For now I just use the old configuration, but ideally I would use the new one.

More info here:

2

i’m going to dig into this soon myself. The first thing i’m going to check is the default php-fpm configuration to see if delay is related to spinning up a new process.

Have you tried this in a fresh or different laravel app to ensure it’s not related to your specific laravel app? I haven’t noticed any bootstrap delay time myself.

3

Thank you for looking into it! I would love to use the new configuration :slight_smile:

Have you tried this in a fresh or different laravel app to ensure it’s not related to your specific laravel app?

I actually did. I ran it in an empty Laravel project, and latency for that default Laravel app is fine:

https://shy-tree-2192.fly.dev

^ that’s a laravel new followed by a a fly launch. Nothing else.

Perhaps it is something about my specific project, but I can’t think of anything that out of the ordinary. And if that’s the case, why is it fast on AWS? A few things I checked:

  • Do I accidentally make connections to external services in AWS? I found some kind of CloudWatch configuration in my config/logging.php so just to be sure I removed that. In fact, today I created a fresh Laravel project and copied all the config files to my “old” project and made some small adjustments until to match my project.
  • I copied all the provider classes from a fresh Laravel project into my project. I noticed the syntax for registering routes changed so I changed that in my codebase.

These things both didn’t matter.

It might be something about the size of the project. Obviously it’s bigger than an empty Laravel project, but it’s not too large. To give an approximate idea of the project size: I have 113 routes and 23 models.

I don’t have any custom providers.

Maybe relevant, the packages that I am using:

    "require": {
        "php": "^8.1",
        "ext-intl": "*",
        "ext-json": "*",
        "artesaos/seotools": "0.22.1",
        "blade-ui-kit/blade-heroicons": "1.3.1",
        "doctrine/dbal": "3.4.0",
        "guzzlehttp/guzzle": "7.4.5",
        "intervention/image": "dev-master",
        "lab404/laravel-impersonate": "1.7.3",
        "laravel/framework": "9.24.0",
        "laravel/horizon": "5.9.10",
        "laravel/sanctum": "3.0.1",
        "laravel/telescope": "4.9.2",
        "laravel/tinker": "2.7.2",
        "laravel/ui": "4.0.0",
        "league/flysystem-aws-s3-v3": "^3.0",
        "livewire/livewire": "2.10.7",
        "lorisleiva/laravel-actions": "2.4.0",
        "maatwebsite/excel": "3.1.40",
        "mollie/laravel-cashier-mollie": "^2.0",
        "moneyphp/money": "4.0.5",
        "nunomaduro/collision": "6.2.1",
        "phpoffice/phpspreadsheet": "1.24.1",
        "predis/predis": "2.0.0",
        "propaganistas/laravel-phone": "4.3.7",
        "sentry/sentry-laravel": "2.13.0",
        "spatie/icalendar-generator": "^2.3",
        "spatie/laravel-ignition": "1.3.1",
        "spatie/laravel-newsletter": "4.11.0",
        "spatie/laravel-permission": "5.5.5",
        "spatie/laravel-sluggable": "3.4.0",
        "spatie/test-time": "^1.3",
        "tightenco/ziggy": "1.4.6",
        "twilio/sdk": "6.40.1"
    },

Not sure if relevant, but the external services I am using:

  • Sentry
  • I have another Fly app running mysql:8.
  • I am using an Upstash redis server created with the Fly CLI.
  • Postmark
  • Twilio
4

Thanks!

I’ve heard reports of Upstash having some latency related to the Fly Proxy layer (which IIRC is getting worked on).

One quick test might be to run your own Redis app just to compare (see how to do that here: Full Stack Laravel · Fly )

5

I have already tested this :slight_smile: I changed the cache driver and queue connection to something other than Redis and removed the redis url from the secrets. It didn’t make a difference.

Thinking about it, why would this suddenly be a problem in the new Docker configuration? If that would be an issue, I feel like that should have also been an issue in the old config…

6

One thing that I can still do is: start removing things from my codebase, until it looks like a fresh Laravel install. Somewhere in between that process the response times should drop. This sounds like an absolute pain though :grimacing:

7

I can’t really replicate this. It seems specific to the app, but here’s a few questions/things:

  1. Is every request slower (~300ms) or just some initial ones? (I’m guessing Sentry is correct and it’s while bootstrapping Laravel, vs something else like PHP-FPM process spin up time).
  2. If you edit fly.toml, set and [env] var to PHP_PM_CONTROL = "dynamic" and redeploy. See if that changes anything (across multiple requests).

That env var is from the base container docs, and it affects how PHP-FPM runs.

However, this seems like something during the bootstrapping to me. Not sure what yet. All my request are in the ~30ms range.

8

Alright, thank you for looking into it. For now it’s running fine on the old config, but when I have some spare time I will dive into it. I’ll let you know if I found the culprit.