7 ms·
Setting up a new connection for every request considered normal for stateless applications? Really? This is a big scaling issue in your stack. You need connecti
by TeeWEE 10y ago
Setting up a new connection for every request considered normal for stateless applications? Really? This is a big scaling issue in your stack. You need connection pooling also for stateless apps.
- chatmasta 10y agoIf 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?
- detaro 10y agoWhat 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.
- CaveTech 10y agoPHP is stateless. You don't get to keep connections across requests.
- trashcan 10y agoI believe mysql_pconnect allows you to keep connections open across requests: http://php.net/mysql_pconnect 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.
- CaveTech 10y agoYou 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.
- trashcan 10y agoI'm not disagreeing with you on the details, but don't both of those things mean it is stateful?
- deleted 10y ago[deleted]
- brianwawok 10y agoThis 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 ;(
- CaveTech 10y agoPersistent 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.
- brianwawok 10y agoConnection pooling is fairly understood at this point in time...
- junker101 10y agoIt'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.
- brianwawok 10y agoThat seems a terrible idea. Don't do that!
- lgas 10y agoWhat does containerizing it change?
- CaveTech 10y agoNothing, 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.
- lovehashbrowns 10y agoI thought it was normal to do connection pooling as well, but I was pretty shocked when I saw how much the API at my job was murdering our PostgreSQL server. Every request meant a completely new connection. So while reads and writes were taking up maybe 10% of the server at peak times, creating and closing connections was taking up easily 5x more than that. If I was particularly unlucky, the PostgreSQL server would stall for a few minutes. Still, I had to implement pgpool-II and do connection pooling that way. It was also a PHP application. :(
- frik 10y agoIt's not a problem for MySQL, it's optimised for that use case and has pooling. I read recent Postgres can handle many connections as well.
- ohstopitu 10y agohow would you go about doing that...especially with FaaS (GCP / Azure / Firebase Functions for example).