Persistent DB connections

[aleho]

Migrating a project from Caddy/FPM to FrankenPHP I noticed that Doctrine was configured to use persistent connections. I'm not seeing any measurable performance impact locally, so I'm curious about your opinions on that matter.

With FrankenPHP in worker mode, are persistent connections still beneficial to performance?

[withinboredom]

In worker mode, there isn't really a need for persistent connections since the connection is simply reused on the next request by default.

From experience, you'll need to check that your app can handle the entity manager being closed and such; since the entity manager may survive into the next request. If you are using an up-to-date symfony/api platform, I believe this is 100% handled for you; but if you are using Doctrine outside of that (or an older version of these), then it is just something to be aware of and make sure you test.

There are a few other "gotchas" to using Doctrine outside of Symfony as well in worker mode, but I won't bore you with them unless you are curious.

[aleho]

Bore me? Impossible! 😁

I'm using Symfony with Doctrine, but I'd still be very interested in the details!

[withinboredom]

Heh, basically things you'd normally need to do in a regular non-php app need to be done.

• ensure the entity manager is always reset/cleared after a request (we do this with a finally in the worker script) otherwise, on an error, it's possible that the transaction is left open and the next request will commit the partial work from a previous request.
• if we detect the entity manager is closed, we simply kill the thread. Trying to "reboot" the connection turned out to be a nightmare at the time -- this was before some Doctrine changes that make this easier for this specific issue; but this works "good enough" for us, for now.
• ensure you're using a shared cache (not an in-memory one!) if you are doing any caching. Otherwise, your cache will survive the request and become stale if another thread makes a change. The in-memory cache is normally per-request in non-worker mode, but this isn't the case in worker mode.
• big queries are currently causing a performance issue ... and Doctrine likes to make big queries sometimes. fix - flushing temporary files after each worker request #1321

There are probably a few other things as well, but those are the big ones I remember running into. We needed a super-high-performance service, and we used Doctrine with a bare-bones framework -- can't remember which one. It's pretty fast and needs to reply within 10ms, or it won't be able to keep up. Symfony is just too slow for what we needed.

[AlliBalliBaba]

The biggest performance increase I've seen was with an application that does lots of IO with S3 (small to medium sized files). Keeping the connection open in this case led to having ~5x better latencies.

There are a lot of other optimizations you can theoretically do on the application side, but I think keeping any connection hot by default is worker mode's biggest strength.

[withinboredom]

Oh yeah; the performance advantages with external services is huge. Especially with things like s3 or microservices!

[aleho]

So, to summarize, worker mode with "default" (non-persistent) connections is enough in your opinion?

On worker restarts a new connection will be created though. Could this even be beneficial?

[withinboredom]

Especially with things like s3 or microservices!

So... actually - this may not be 100% the case. We literally just discovered an issue where we have cached a DNS entry that causes issues. For example, if you have a service with several A records, it will always use the first one. This seems like an application-level issue, but something to be aware of nonetheless.

[AlliBalliBaba]

Worker mode will generally be faster even if you don't optimize anything application-side (especially with Frameworks like Laravel that do a lot of bootstrapping). The more work you do per-request, the less the impact will be though since at some point you're just executing PHP.
Most web applications are IO bound though, so being able to reduce time spent doing IO can be much more beneficial.

I gave S3 as an example since its SDK will usually have to authenticate first to establish a connection. So in traditional PHP applications you have to go through authentication on every request. Worker mode will just have to authenticate once for every ~1000 requests. So you're first request will be as slow as non-worker mode, but the following 999 requests will be a lot faster when running hot.