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.
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.
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 ;(
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.
> 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.