views:

342

answers:

2

I don't want to make a holy war. I just want to know if there is such benchmark? Or maybe you can say something about this thread from your experience?

+4  A: 

I just stumbled over the language shootout yesterday, again where you can compare some performance characteristics of both languages while running different programs. I didn't find a benchmark for web performance, though.

Fact is, that interpreted languages like PHP are always slower than a compiled language. JSP files get compiled, too, so once the server is up an running and doesn't get changed anymore, the performance will be better than a PHP script that gets interpreted every time a request comes in.

On the other hand, the first performance bottleneck you will have will probably be the database speed, anyway. And then there are still lots of other ways for improving performance like pre compiling your PHP scripts, externalizing heavy calculations into C etc. And compared to the monster of Java web development PHP is easy to learn and to get along with. In the end, if you have the choice, you should go with the language you are most comfortable with. If you are starting a new project you may not even know if all the performance considerations will ever be important because you don't have the users yet and just want to get your application out there quickly.

Daff
+2  A: 

While Daff's explanation of PHP vs JSP is technically wrong, the essential gist of his post is correct: choose the language that is best for you. Only very rarely will you find yourself in a position where performance really matters badly. At that point, you are much more likely to be able to make significant architectural optimizations in your language of choice - and these optimizations are likely to have significantly more effect than the difference between PHP and JSP.

One of the core rules of programming has always been to avoid premature optimization - if for no other reason than because until you're actually under pressure you don't know what you actually need to optimize, nor do you have a means of determining whether it worked.

In the event that you believe there's a possibility you may face performance issues, no website can help you. The most vital thing is to create your own load testing benchmarks that represent the specifics of how your site works, simulating how your users do things. Only once you have done that are you able to move on to tweaking your code, implementing things like caching, load balancing, data and request partitioning etc with any confidence that the changes you are making are having a positive impact on your site performance.

There are books specifically about the process of optimization in general, but the key sequence is this:

  1. Benchmark
  2. Change test
  3. Benchmark to see if change indicates performance improvement
  4. Go live
  5. Evaluate live response to see if benchmark prediction was correct

(People forget #5 a lot and cause themselves grief)

If you're going to spend time worrying about performance, spend time setting up that sequence, don't spend time worrying about your language choice.

Richard Clark
I have no problem to set the explanation right. But you just stating that it is wrong without saying why doesn't help very much with that...
Daff
I believe that your generalization of "avoid premature optimization" to "avoid optimization until customer complains" is incorrect. You should always choose the *best*_algorithm_ for the purpose and then use it in the simplest way possible while still being correct. Then occasionally bottlenecks occur in unexplected places, but then you rarely have to rip out the guts and replace it with something new, but merely find the bottleneck and give it special attention (in form of something more complex but still correct).
Thorbjørn Ravn Andersen