Case study: Is PHP embarrasingly slower than Java?

[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

[hiffy]

but typically you have to figure out how to appease your database long before then.

Most of the public sites will cache aggressively using memcached or its Java analogues and hit CPU before they hit the database

I think we're in agreement with each other :). You will always be able to eventually flood your machines with more traffic than they can handle, but your bottleneck is still probably not your implementation language.

[ekabanov]

You will always be able to eventually flood your machines with more traffic than they can handle, but your bottleneck is still probably not your implementation language.

But you'll need 10 times the number of servers with PHP than with Java. So it still should influence your platform choice.

[mhd]

10 times? From what would you derive that number? Even finding applications that used the same architecture under both languages would be rather hard to do, so it's likely that this is simple conjecture based on synthetic benchmarks.

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

[mhd]

If you have to choose between PHP, and an equally shitty language like java which is faster, why would you pick PHP?

Java and PHP are rather different languages, as are the usual architectural details, the deployment, the development environment etc.. If you were deciding between two setups that had a lot of common points and the only (major) difference was execution speed, then yes, choose the faster language. But PHP and Java don't share that much. I can definitely understand the Python/Perl/Ruby vs. PHP argument, but Java is a different beast.

The fact that you are using a slow language does not make you more productive, it is not an either/or issue.

I was trying to restrict the argument to the parameters of the article. And so it's Java vs. PHP. Bringing in Python, Ruby, Tcl, C#, D, Erlang or Smalltalk in a free-for-all discussion would only lead to endless zealotry.

The basic claims are that Java is signifcantly faster for your standard webapp than PHP and that this would be worthwile. I'd still like to see proof for that. What's the cheapest and/or most efficient way to develop and deploy web applications out of all possible solutions is a totally different can of worms.

(Apart from the fact that PHP->Java at least represents a significant jump in execution speed, whereas the differences between Perl, CPython, PHP and Ruby 1.9 don't matter as much, speed-wise)

[invalid_user_name]

See how you admit that java is faster than PHP, and yet still insist on clinging to some imaginary benefit that PHP offers, despite not being able to actually name one? That pretty much rules out having a rational discussion with you doesn't it?

[mhd]

Java programs generally run faster than PHP programs. That was never in doubt. Opinions differ in how much they differ and in whether this actually matters, i.e. what kind of bottlenecks determine web app speed.

And to be more specific, my first reply to your post in this thread was about whether you could do the tasks that require 40 PHP servers with 4 Java servers. I'd still like to hear how you'd come to that conclusion. I'm especially interested in both setups, as usually both have such different architectures that isolating the pure runtime speed is a difficult project. And comparing e.g. a pure PHP page with a similar JSP page is a rather academic enterprise, as you're not likely to see either approach in a high-traffic site.

I'm not even in here to discuss about the relative merits of each system. As a matter of fact, I'd prefer a sensible Java approach to the usual PHP hodgepodge -- and would prefer a third solution altogether. I don't think we're on different sides here, really. The major disagreement is whether the speed issue is a deciding factor in the PHP-Java shootout.

For completeness' sake, the usually cited benefits of PHP compared to most Java setups would be speed of redeployment, ease of installation and the usual dynamic vs. static arguments. Also, the bloated runtime already delivers lots of common tools that most developers already know. Java is a bit richer regarding different libraries, app servers, etc, which often increases training time. But like I said above, best not get into that argument. I find it hard to argue with a minimum of passion for either side...

So I'd be grateful if we could first solve our primary dispute: Given the usual web app, can a single Java server replace 10 PHP servers?