> Then don't mess up. It's not that hard. If you follow best practices (don't use global variables) you should handle this fine. I haven't heard anyone having this problem in Rails at all.
Sure, though how do you know all the library code you are using isn't going to mess things up for you? Granted, chances are small, but they are there.
> No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.
Use a cache for your bytecode to not re-parse all the time. Use a special purpose TCP proxy to keep connections open if that is your bottleneck (in most web apps it's not). Also, certain DB drivers let you have persistent connections out of the box.
> It's perfectly possible to write a shared-nothing architecture without dumbing it down to CGI.
It hasn't been done yet for the price that PHP offers. It is very limited in some areas, but if you go with the grain, it is very cheap.
My main point is that two different applications cannot share an interpreter in RoR/Django/nodejs. This leads to overhead which is not there for PHP. Places like Heroku and Google App Engine try to be clever about this. You can technically shut down interpreters that aren't used frequently, and spin them back up when many requests come in, but guessing when to shut things down and spin them back up is tricky. This is why Google App Engine is so pricey: they suck at figuring this out. But even if you have a great way to figure it out, you are still going to have unpredictable performance, and the cost of waking up/spinning up an interpreter is fairly high.
> Sure, though how do you know all the library code you are using isn't going to mess things up for you? Granted, chances are small, but they are there.
> Also, certain DB drivers let you have persistent connections out of the box.
If you have connection pooling you have have a "dirty environment". PostgreSQL/MySQL makes it possible to set per-connection settings so you have no guarantee that the SQL executes in a clean environment. You might say that "oh, but the library handles the resetting for me", but how do you know all the library code you are using isn't going to mess things up for you?
You got me :). And not only is it a possibility, but actually a certainty, if you set your own settings and don't re-set them on every new connection. This is an issue with all frameworks that allow persistent connections. For example a while ago I was working on a Django app where I needed to have the timezone set to the user's timezone when talking to MySQL. This meant that on every request I'd have to re-send a query, setting the timezone even if it did nothing. Alternatively, if I relied on the default timezone being UTC, I still had to set it explicitly, because the prior request might not have cleaned up after itself properly.
In short, unless your database has a way of saying "reset all settings", you cannot have persistent connections in any environment.
Sure, though how do you know all the library code you are using isn't going to mess things up for you? Granted, chances are small, but they are there.
> No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.
Use a cache for your bytecode to not re-parse all the time. Use a special purpose TCP proxy to keep connections open if that is your bottleneck (in most web apps it's not). Also, certain DB drivers let you have persistent connections out of the box.
> It's perfectly possible to write a shared-nothing architecture without dumbing it down to CGI.
It hasn't been done yet for the price that PHP offers. It is very limited in some areas, but if you go with the grain, it is very cheap.
My main point is that two different applications cannot share an interpreter in RoR/Django/nodejs. This leads to overhead which is not there for PHP. Places like Heroku and Google App Engine try to be clever about this. You can technically shut down interpreters that aren't used frequently, and spin them back up when many requests come in, but guessing when to shut things down and spin them back up is tricky. This is why Google App Engine is so pricey: they suck at figuring this out. But even if you have a great way to figure it out, you are still going to have unpredictable performance, and the cost of waking up/spinning up an interpreter is fairly high.