6 ms·

> You can mess up and create a dirty execution environment. Then don't mess up. It's not that hard. If you follow best practices (don't use global variables) y

• IgorPartola 14y ago
  > 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.
  • judofyr 14y ago
    > 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?
    • IgorPartola 14y ago
      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.
• polyfractal 14y ago
  > 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. What? This is all factually incorrect. 1) PHP has supported persistent database connections for ages. The fact is, persistent DB connections aren't really that great for websites, where you need a few resources quickly and then nothing for a long time. Having 10,000 idle DB connections is a great way to eat up resources. But you can do it. 2) PHP can use cURL's multi-handles, providing a per-application keep-alive connection pool (e.g. see Guzzle: http://guzzlephp.org/tour/http.html#managed-persistent-http-connections http://guzzlephp.org/tour/http.html#managed-persistent-http-...). 3) While not part of PHP itself, most serious PHP applications use something like APC, which caches PHP opcodes to prevent constant reparsing.
  • papsosouid 14y ago
    >The fact is, persistent DB connections aren't really that great for websites, where you need a few resources quickly and then nothing for a long time. Having 10,000 idle DB connections is a great way to eat up resources. But you can do it. Which is why you should be using connection pooling. Which can not be done efficiently with PHP. Necessitating that people create an entire extra layer of database proxying software to do the pooling for you.
    • polyfractal 14y ago
      Ah fair point, I misinterpreted the grandparent's statement in terms of persistence, not necessarily pooled persistence.