This is one of the reasons where PHP makes stuff so complicated.

Django out of the box its 1 flag to keep connections alive. I assume most other languages as well.

You CAN do it the right with with PHP if you use a bunch of other products, but you are making life so much harder than it needs to be ;(

Persistent connections are far more complicated to reason about. I believe what you mean is that this makes it more difficult to scale PHP, which is arguably true, but at the same time it forces you to understand underlying concepts.

Connection pooling is fairly understood at this point in time...

It's typically 'SESSION' specific things with connection pooling that I've seen underlying (sometimes long-uncaught) bugs in production systems.

e.g. A 'ALTER SESSION'/'NLS_DATE_FORMAT' commands in Oracle or even an unfortunate 'USE <db>' w/MySQL.

There are of course safe solutions & techniques for this, but when you have an otherwise stateless-by-design codebase (such as with PHP), picking up "possibility state-laden" connections is a bit of an unexpected concept that I've seen catch developers more than once.

That seems a terrible idea. Don't do that!

What does containerizing it change?

Nothing, but the 2 parent comments both make strange statements which leads me to believe there is a misunderstanding.

> If you are containerizing your stateless app, where do you store the connection pool? I suppose you could setup another container as a TCP proxy that can maintain persistent connections and then connect to redis through the proxy?

Containerizing doesn't prevent you from having a connection pool, but PHP doesn't allow you to have a proper connection pool regardless. I believe there is a misunderstanding on containers here.

> What do you mean by "containerizing"? Unless you restart app instances for every single request, I don't see how connection pooling is an issue. Just putting a worker in a container doesn't stop it from keeping a connection open.

This comment corrects the misconception about "containerizing", but then overlooks that PHP is effectively restarted per request.

I believe mysql_pconnect allows you to keep connections open across requests: http://php.net/mysql_pconnect

Additionally it is definitely not stateless, the session cache persists between requests as well. You can just load balance between 20 php-fpm instances without moving the session cache to something shared.

You can do persistent connections but it only applies to the same child process and you don't have fine grain control over this process if you choose to use it. Session cache is stored on disk.

I'm not disagreeing with you on the details, but don't both of those things mean it is stateful?