Hacker News Reader

Comment by judofyr | Hacker News Reader

> 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) you should handle this fine. I haven't heard anyone having this problem in Rails at all.

> I detest writing code in PHP for many reasons, but the execution model is efficient

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.

(Added later: Yes, this isn't how PHP actually works, and that was kinda my point: parent's concept of "PHP execution model" isn't actually used in PHP because it's stupid! There will always be some things that you want to share (connection pooling, opcode cache) so even PHP isn't a "perfect" share-nothing architecture.)

It's perfectly possible to write a shared-nothing architecture without dumbing it down to CGI.

View on HN

> 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-...).

3) While not part of PHP itself, most serious PHP applications use something like APC, which caches PHP opcodes to prevent constant reparsing.

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

Ah fair point, I misinterpreted the grandparent's statement in terms of persistence, not necessarily pooled persistence.

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

Reply on news.ycombinator.com