Arrow of time
Arrow of time

JSP Performance - I have stumbled upon an oxymoron

Share Tweet Share

As one of the commenters figured out, I made a fatal error in not running Tomcat as a standalone server …

As one of the commenters figured out, I made a fatal error in not running Tomcat as a standalone server, which had a horrible impact on its performance. After fixing this, the performance results between PHP and JSP are very near, probably within measurement error.

So I'm retracting this too-hastily written post and apologize for any grief it caused to Java users :)

It is the year 2011 and the "Java is slow" notoriety still isn't dead - and rightly so. In choosing the technology for a project I vas sort of leaning to use Java (or is everything which combines Java and the Web automatically called J2EE?) instead of PHP which I normally do (for better or for worse). I was expecting Java to be more optimized and together with JIT compiling, the faster solution. But I tend not to assume and do my own benchmarks so imagine my surprise...


The hardware: my small laptop, dual-core AMD Athlon 2 Neo, Ubuntu 11.04 x86.

The Java side: Tomcat 7.0.11 (bundled with NetBeans 7), sun-jre6, a simple Hello, World JSP page which sets and writes out a property of a (session-bound) bean, i.e. several lines of template HTML code with jsp:useBean, jsp:setProperty and jsp:getProperty directives in the middle.

The PHP side: apache 2.2-worker-mpm, PHP 5.3, php-xcode accelerator, PHP as FastCGI with fcgid; a simple Hello World PHP page which sets and writes out a session variable, i.e. several lines of template HTML code with a couple of lines of PHP in the middle, starting a session, setting a variable and writing it out.

The benchmark: Apache's ab with concurrency of 2 and 500 total requests. Note that this benchmark will start a new session for each HTTP operation in both cases.

The results: slightly over 900 requests/s with PHP and 62 requests/s with JSP.

It turns out that the JSP performance is the same even with a pure HTML page without any JSP invocations. Enterprisey indeed.

This is a so outrageous result that I'd really want to hear from regular J2EE developers on similar performance comparisons!


#1 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-07-29T18:06 by Svebor
It will scale if you put it in the cloud, and that's all that matters..the cloud. :-)

#2 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-04T14:18 by Ari

PHP runs HelloWorld 15 times faster than Java

Conclusion: use PHP for HelloWorld-like projects.

Real benchmarks

http://shootout.alioth.debian.org/u32/php.php

#3 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-04T14:54 by Simon

Try to using Tomcat without Netbeans: I bet you use the Netbean's debug mode!

#4 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-04T18:29 by Ivan Voras

Regarding "Real benchmarks" - I won't argue that JIT-ted Javan can calculate fractals much faster than PHP. I would like to find a similar JSP vs PHP benchmark.

The "use Tomcat alone instead of NetBeans" is the better advice. I will try it!

#5 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-05T10:23 by Ari

Ivan. Even with a standalone TomCat I think your article is still very weak.

I think you should compare JSP and PHP with a more meaningful, real-world example. Actually, HelloWorld is one of the worst example you could do, even if results now satisfy Java fans.

As clearly explained here (http://stackoverflow.com/questions/691942/speed-of-code-execution-asp-net-mvc-versus-php) stacks like ASP.NET or J2EE offers the opportunity to produce pages that are **not transient**, which is **impossible** in PHP (because there's no Application Server in PHP world), and that makes THE difference.

For example, everytime you send an HTTP request to a PHP server (like in your Hello World test), PHP starts the whole framework, it creates database connections from scratch, executes code, frees memory and so on. The key, here, is that finally everything is destroyed.

In a Java web application, on the opposite, the stack provides a **persistent** database connections pool; objectes can survive the HTTP request and so on.

That makes THE difference. Incidentally, that is on of the elements you didn't benchmark.

Your benchmark is like comparing the speed of a bicycle and a car on a 100Km road with the repetition of 2 meters runs. And you are turning on and turning off the car's motor everytime. Hey, man: if you want to compare cars and bicycles, let the car run, and you will discover that the little overhead of turning on the motor will be trascurable when the car will be running at 150Km/h and the bicyle will still be limping.

Measuring the speed of a "echo $someString" is really balooney.

Java and PHP are meant to manage more complex stuff than this. Measure their performance on a real-world example.

Or you could conclude that the best programming language on the web is HTML itself, since

<html><body>HelloWorld</body></html>

is 10 times faster than PHP.

#6 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-06T00:59 by Ivan Voras

Ari, luckily this is the Internet and everyone is welcome to express his opinion :)

As engineers, doing simple back-of-the-envelope benchmarks is a normal thing we do to get a rough gauge of any technology or environment. I was surprised by the low result I got with JSP, and I hope it shows in the last sentence of my original post - Java after all does have a large toolbox of technologies (some even patented ;) ) which should indicate that it's should be better then I found it.

I *am* glad that it turned out to be due to pilot error (i.e. mine) - but sooner or later I would have returned to investigate it in depth to try to repeat the result.

Regarding if a "hello, world" JSP is a good enough benchmark: I am sure you will agree that in todays dynamic, AJAXy web applications, doing very short HTTP requests fast is a very desired feature.

#7 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-06T01:06 by Ivan Voras

Just to try and make myself clear: my benchmark was wrong, it contained a big configuration error (it should have occured to me that running it from within Netbeans would add debug hooks & other overhead), and I am very glad to have been taken to school on the subject.

Regarding schooling, I will also take this opportunity to educate you that the issue of "non-transient" pages in PHP is false, as sessions, databases and cache servers (like memcached) have taken some of the roles of monolithic application servers. For some architectures (e.g. like facebook's), this is the only way to scale - which would be impossible with the Java's model. In addition to this, persistent database connections have been in PHP for more than a decade.

I consider this thread closed :)

#8 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-08T11:17 by Ari

Sessions do exist in PHP, of course. But non-transient objects are a bit more complex, and definetely not supported by PHP.

Memcached (like other addons) is meant to cache (as the name says), not to "keep object live". I mean: can you have a PHP running algorythm between two HTTP requests, for example a scheduling class? Even memcached cannot add this feature. Please, don't misurderstand me: ***I don't say it's a lack***: I just stress that PHP is meant to pricipally work in a state-less way; in the opposite, Java is meant to run in an Application server context.

The distinction is not that sharp, and you can find state-less elements in Java (like static pages) and state-full elements in PHP (like Sessions and persistent connections)

I consider the thread closed as well: thanks for the topic. Bye, have a nice day

#9 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-12T09:52 by mrt

Ari, your explanation does not make sense. Have you been smoking something lately? Memcached keeps objects, data structures and so on in memory so that you do not need to re-create them on every request. I still don't see the advantage of your so called "non transient object". With memcached you can actually scale even further since it's distributed, so you can spread the load across multiple nodes, it's not bound to a local system only. What feature memcached cannot add?

Plain and simple Java is still slow and extremely annoying to develop with.

#10 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-12T14:40 by Ari

Ok, you're right. Java is slow and annoying.

Have fun.

#11 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-12T16:43 by Eph

Ivan say: "For some architectures (e.g. like facebook's), this is the only way to scale - which would be impossible with the Java's model."

Some time ago I read that Facebook currently use PHP only for the template engine, now everything else is Java.

mrt say: "With memcached you can actually scale even further since it's distributed, so you can spread the load across multiple nodes, it's not bound to a local system only"

This statement is ridiculous! In all Java environments where I worked there were at least two nodes that cooperated with each other in clusters ... not that it is impossible to have six cluster servers that can work in PHP, I'm just saying there are in Java application servers that are automatically.

#12 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-12T16:51 by Ari

@Eph: You're right. Facebook uses Java, Erlang, Python and C++. No PHP. Not anymore, anyway.

Facebook planned to completely abandon PHP. They were unable, because

"Since 2007 we've thought about a few different ways to solve these problems and have even tried implementing a few of them. The common suggestion is to just rewrite Facebook in another language, but given the complexity and speed of development of the site this would take some time to accomplish. "

Haiping Zhao (Senior Software Engineer Facebook) sais.

Being unable to abandon PHP they wrote a tool, HipHop, in order to convert it into C++. Since that day, there's no PHP running on Facebook's servers:

HipHop allows us to write the logic that does the final page assembly in PHP and iterate it quickly while relying on custom back-end services in C++, Erlang, Java, or Python to service the News Feed, search, Chat, and other core parts of the site.

Hence, I could not say "For some architectures (e.g. like facebook's), this is the only way to scale - which would be impossible with the Java's model".

Believe of not PHP was one of the biggest problems Facebook had in achieving scalability. Java was one of the solutions chosed.

http://developers.facebook.com/blog/post/358/

#13 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-16T07:48 by Mike LaGarde

@mrt: "What feature memcached cannot add?"

This one, for instance.

@Singleton
public class UpdateSubscriptions {

   
@Schedule(hour="*/6", minute="0", second="0", persistent=false)
   
public void run() {
       
// Do your job here.
   
}

}
No way without the "so called non-transient objects"

#14 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-16T09:52 by Ivan Voras
@Mike: you got it all backwards. If you are running php, you are also running a unix/linux environment and the thing you just described is called a "cron job" and a feature present since forever. This is a large part of what irritates me about the Java community: problems which you are trying to solve were already solved before you, and probably better and less complex. In this case, just think of memcached and others as "distributed persistency servers" and accept it.

#15 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-16T14:34 by Mike LaGarde

No need to take it out on me, Ivan :)

I AM a PHP developer and I don't use Java.

mrt asked for features not supported by memcached. This is just one. You're right: crontab does the same job. Nevertheless memcached nor Apache cannot, Java with Tomcat can.

memcached is able to persist objects and it's great (I'm a happy user): but it's definetely not an application server context, which is completely different. An application server allows running and alive objects to survive PHP applications themselves, which is absolutely not one of memcached objectives.

I will continue using PHP, since it is much more suitable to my needs, but persisting on claiming "PHP can do everything Java can do" is silly to me.

#16 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-16T15:01 by Mike LaGarde

Please, also note that the "singleton" attribute in the Java chunk I posted before really means singleton. 1000 http requests uses the same single class. Singleton in PHP just means only-one-instance-in-the-application, but unfortunately, even with memcache* infrastructure 1000 requests generates 1000 applications and consequently 1000 singleton classes (even if quickly deserialized from the cache layer).

PHP singleton scope is request scoped, Java is not.

#17 Re: JSP Performance - I have stumbled upon an oxymoron

Added on 2011-08-16T15:33 by Ivan Voras

Assuming that you want to reimplement a Java application in PHP or vice-versa, I can see how you may think that. But that's plain wrong.

The only thing we can agree is that these are different systems and concepts do not translate literally - everything else will turn this thread into a flame war, and so I'm disabling comments to this post.


comments powered by Disqus