High TTFB

[larskoole]

I'm experiencing a rather high TTFB of around 200ms consistently. Is this something you are also experiencing @gregmsanderson? If so, I'll dig into it some more.

[gregmsanderson]

It isn't, but there are a range of factors involved in TTFB. The biggest of which is where the vm is compared to where you are. When you deploy initially, you can choose a region. However subsequent deploys may not deploy to that same region. It depends on latency, capacity etc. You can check which region(s) your vms are currently using with fly status. If you have a vm in say, iad (US) but you are in say, the UK, well the TTFB will be high as each request has to travel across the ocean. So first thing to check is your vm is indeed the one close to you. Then check you are being served by the closest vm. Which sometimes is not the case, because of anycast quirks. If you have more than one and you want to see which of your vms returned the request, either use fly logs or add a header to the response (e.g see https://github.com/gregmsanderson/fly-hello-laravel-db-replay#apphttpmiddlewareflyheadersphp).

Assuming the request is being served by the closest vm, is your app causing any additional latency? The permissions I used are currently quite permissive and so should allow Laravel to cache e.g views. However if your app does any "thinking" and/or database requests (of course the sample app doesn't as it just shows a welcome page) that will also increase latency, beyond any added by location. So it's hard to debug. Definitely look at fly status and fly logs to see if they reveal anything about location and/or errors slowing things down though.

[gregmsanderson]

I perhaps should also add that Laravel is not the fastest framework, generally. If speed alone is your primary concern, it's probably not the best choice. It loads lots of files! So it really depends on what you are comparing it to, in terms of TTFB, to give a true comparison. It would need comparing across e.g a similar paas to narrow down a particular issue, like with Fly/networking etc.

[larskoole]

Thanks for your elaborate response!

I'll assume it has something to do with my configurations and/or database calls (database as session driver) and do some more research to see if I can optimise my build.

Locally I can get sub 80ms TTFB (with database calls) so it must be something I can fix 😄

I'll close this issue for now and if I find anything that may help others I'll post it here :)

[gregmsanderson]

You're welcome.

I should also add that one performance boost is from pre-caching (routes, config etc). You'll probably see a mention of doing that in the Laravel production guide and wonder why I didn't. There are some consequences of doing that, so I made things simple by clearing any cache as part of the build: https://github.com/gregmsanderson/fly-hello-laravel/blob/main/Dockerfile#L107

But if the app is having to interact with the database on every page request (to check the session), that would certainly explain a delay. You could see if it is that by temporarily using a file (not in production!). If so, maybe try Redis? That's generally super-fast as a session store.