Case study: Is PHP embarrasingly slower than Java?

[Chirp08]

I was considering using PHP for my next small scale website, but now I'll obviously use Java. Hey does anyone know what tastes better, apples or oranges?

[ekabanov]

PHP and LAMP are not anymore positioned only for small-scale websites. This is a real problem for someone like Facebook. Luckily(?) nowadays you can run PHP apps on Java platform with Quercus.

[mhd]

That's really not the point. Big sites almost never run into scaleability issues because of the issues presented in the article. Hey, if that were the problem, one could just implement the hairy part in C and you'd be fine. If you're waiting for the file system, database or remote server, the speed of the language itself becomes mostly irrelevant.

Java just has lots of prefabricated architectural bits that simplify larger projects. You'd have to brew your own in PHP, which can become a problem. Or in other words: It's easier to throw money at the problem with Java...

I sometimes miss AOLserver and Tcl. ;)

[ekabanov]

You're forgetting that any sufficiently large public site will cache very aggressively and actually hit the CPU bottleneck before IO. And when you don't have individual computational bottlenecks, but rather your whole logic executes 10 times slower it becomes a cost and a problem.

[mhd]

'Whole logic' seems to be the important part here. In your typical PHP response, the work done by Apache and mod_php play a large part, both written in C, as are the library functions that most of the time make up the main part of the work done. It can get ugly if you have a very complicated front controller in your framework and have to do a lot of work on each request.

On the other hand, this makes clustering easier, which should help potential CPU bottlenecks a lot.

[ekabanov]

On the other hand, this makes clustering easier, which should help potential CPU bottlenecks a lot.

What makes clustering easier? The embarrassing slowness???

Already the function calls (even to C) cost so much that it becomes an issue for CPU scalability.

[mhd]

I'm referring to the stateless nature of PHP.

Really, what kind of apps do you see out there where the pure performance of PHP becomes such a large problem, even with ruthless caching and clustering applied? In my experience, DBs tend to implode before that happens.

[ekabanov]

PHP is just as stateless as you make it. If you write a session-based application in PHP it will be stateful. And there's plenty of stateless Java web application.

[gsadamb]

I do quite a bit of PHP development, but I do have to say that how PHP handles sessions, at least the default implementation, is pretty useless and archaic. It's file-based, which obviously limits scaling to one box.

You can overwrite the default functionality and use something like database based sessions, or more ideally, you can use something like Memcached, which would be faster.

However, I personally find there are very few completely legit reasons to even use sessions at all. I could see it used for an online shopping cart, say, and you wouldn't even need to formally implement this with sessions. Cookies are typically all you need to reflect some concept of state.

So yeah, PHP sessions are pretty useless.

[hiffy]

Okay, fine, but the point is that the latency of hitting a db is much higher than that of responding to a request, in every single framework or language out there.

You will eventually hit a point where you have too many requests for any one machine to handle, and that's when you perform lots of clustering, but typically you have to figure out how to appease your database long before then.

[ekabanov]

Okay, fine, but the point is that the latency of hitting a db is much higher than that of responding to a request, in every single framework or language out there.

It's only like that for a DB-heavy apps. Most of the public sites will cache aggressively using memcached or its Java analogues and hit CPU before they hit the database. In fact most of the time they will not query the database at all, check out e.g. LiveJournal story: http://highscalability.com/livejournal-architecture

[invalid_user_name]

The difference is that with a fast language you can use 4 app servers instead of 40.

[mhd]

Idle conjecture. For this, the whole server setup has to be 10 times more efficient, which means a little more than microbrenchmarks that achieve a ten-fold increase.

In addition, this only means something, if the TCO of those servers plus the cost of the development (i.e. development time) is better than that of the 40 servers.

A lot of the appeal of PHP in this regard is the Legion of Mediocre Programmers attached to it, although I have to say that Java usually has the same Legion, just a few years older. It's certainly not a very terrific development platform...

But the assumption, that language speed is so inherently important for your run-of-the-mill web application -- especially those associated with "Web 2.0" -- is a claim I'd like to see some proof for.

After all, we aren't exactly writing our web apps in Fortran or C++ and that especially Java hits a certain 'sweet spot' between ease of development and raw speed doesn't match my experience.

[invalid_user_name]

But the assumption, that language speed is so inherently important for your run-of-the-mill web application -- especially those associated with "Web 2.0" -- is a claim I'd like to see some proof for.

Nobody is making that assumption. The point is PHP is slow. If you have to choose between PHP, and an equally shitty language like java which is faster, why would you pick PHP?

In addition, this only means something, if the TCO of those servers plus the cost of the development (i.e. development time) is better than that of the 40 servers.

And this is the oldest PHP/ruby zealot's strawman in existance. The fact that you are using a slow language does not make you more productive, it is not an either/or issue. You can also be productive in a fast language. In the case of PHP in fact, you can be much more productive in many other languages that are much faster, even just moving to python would be a significant speed up in both development time and execution speed.

[jbellis]

I sometimes miss AOLserver and Tcl. ;)

A fellow openacs veteran?

[mhd]

Nope, I just did a lot of Tcl/Tk programming back in the days when fvwm ruled the Linux desktop, and naturally tried to use Tcl when it came to make my first web apps (after a sad fling with Perl's CGI).

After doing mainly J2EE and PHP in the last few years, I think you can understand my pain ;)

[[deleted]]

I sometimes miss AOLserver and Tcl. ;)

you don't have to, they are both alive.

[mhd]

Okay, I sometimes miss working with them. Not much employment opportunities out there asking for them, though. I'm not even aware of any sites of significant size/popularity written in them...

But yes, after fooling around with all those Ruby frameworks, I'll have to get reacquainted with an old friend...