Slashdot Mirror

Actually, Perl and PHP do compile to their own opcode trees which get cached (by default in Perl or with an "accelerator" in PHP). Despite the flawed benchmark shown here, mod_perl is faster than Caucho. See this benchmark for more.

This benchmark is both ancient and wrong. I can't speak for the PHP code, but the mod_perl code is not done in the way that an experienced mod_perl programmer would do it, and thus does not demonstrate the best performance mod_perl can give in this situation. It would be better to look at this benchmark instead.

I call bullshit on the PHP is faster part:

http://www.chamas.com/bench/#2000

Um, as someone who used Java extensively and is a Sun certified Java Architect, I think you're statement about Java being better suited than Perl for web apps is misleading.

You're talking about directory mapping in Apache vs Tomcat for goodness sakes. If you wanted to make a case, say something about performance, scalability, memory footprint, available apis & free components, programmer productivity, lines of code required for most common tasks needed in web apps, etc.

BTW, for all of you brainwashed into believing that Java is faster than Perl for web applications (like I was), take a look at some benchmarks or better yet, perform your own benchmarks based on how YOUR web applications will run:

Several Perl and Java Benchmarks


Equating Perl web apps to just cgi is like equating Java only to browser-based java applets. Both Perl and Java have much more to offer than cgi or applets. Perl has mod_perl and fastcgi for performance as well as persistance. Java has jsp, servlets and ejb.

Frankly I always like servlets better than jsp and usually like servlets bettern than ebj. Servlets are great for the bulk of web apps.

But once you try Perl using mod_perl or fastcgi, I think you'll realize that there Perl can be a much more productive environment where apps will use much less memory than Java and run more quickly as well in most cases.

I still like Java (and C) and I've coded Java for at least 3-4 years longer than Perl. But I find that for similar tasks, I can get things done with Perl in 1/2 the time than it would take me in Java. Even more quickly if the coding involves processing text files like xml or html.

Again, try learning/using competing technologies until you're considered very good or an expert in both, run your own benchmarks, then tell the world what you think is better.

Loyalty to languages, operating systems or other technologies for its own sake is very silly. Get good at several things (choose wisely) and use whatever is most appropriate for each situation.

If you're going to look at benchmarks, I'd suggest looking at both the Caucho and Chamas benchmarks:

Caucho benchmark
Chamas

It's worth keeping in mind that Resin is Caucho's main product. I'm not claiming that Caucho distorted their benchmark in any way; I'm just pointing out that they have a vested interest in the outcome of their benchmark.

Similarly, Chamas is the originator of Apache::ASP. Again, I'm not claiming that Chamas distorted their benchmarks in any way, but it is always wise to be aware of potential conflicts of interest. Though in the case of Chamas, the potential conflict is respect to Apache::ASP vs. other technologies rather than Java vs. PHP.

Hmm, I use both Java (JBoss) and PHP. Maybe I should make my own benchmark.

I'd say that if you are primarily interested in failover, message queueing, and the other stuff addressed by J2EE, go with JSPs/servlets/EJBs. If you want to build and deploy something quickly, cheaply, and with low performance overhead, go with PHP.

If you're going to look at benchmarks, I'd suggest looking at both the Caucho and Chamas benchmarks:

Caucho benchmark
Chamas

It's worth keeping in mind that Resin is Caucho's main product. I'm not claiming that Caucho distorted their benchmark in any way; I'm just pointing out that they have a vested interest in the outcome of their benchmark.

Similarly, Chamas is the originator of Apache::ASP. Again, I'm not claiming that Chamas distorted their benchmarks in any way, but it is always wise to be aware of potential conflicts of interest. Though in the case of Chamas, the potential conflict is respect to Apache::ASP vs. other technologies rather than Java vs. PHP.

Hmm, I use both Java (JBoss) and PHP. Maybe I should make my own benchmark.

I'd say that if you are primarily interested in failover, message queueing, and the other stuff addressed by J2EE, go with JSPs/servlets/EJBs. If you want to build and deploy something quickly, cheaply, and with low performance overhead, go with PHP.

PHP is fine, but it's not as fast as mod_perl.

While there are some numbers here available for your review, benchmarking does not provide a real world assessment for any application operating in a specific real world scenario, and this does not try to demonstrate any proof that any system is better than any other. More often than not, the benchmarks themselves are are too simple to fully utilize an application's strength or reveal its weaknesses. The benchmarks instead tend to be written for a lowest common denominator so more web applications can compete than not.

Welcome to the Hello World! benchmarks. This site seeks to give its visitors a sense of web application execution speed on various software platforms running under the Apache web server. ...... The benchmarks instead tend to be written for a lowest common denominator so more web applications can compete than not.

You never heard of mod_perl, FastCGI, Embperl, or the Template Toolkit if you're still talking about PERL CGI scripts, have you?

Apache and PERL is still the bleeding edge of web developement. It's just no more alone at the top. Perhaps you should take a look on these Benchmarks. Especially the JSP don't look very good there and Embperl2 is usually very close to PHP regarding performance. Only Apache modules written in C are without real competitor. But you should also think about the ease of developent if you compare C code with PERL, PHP, ASP or JSP.

Please don't knock php as "hackish" programming and then praise perl. I could note that some of the most obfuscated code i ever see is written in perl. I won't. :)

Instead i'll note that the quality of the code in any programming language is all in how you write it. It's true that php lends itself very well to dropping snippets of code into html. As a professional web developer, however, i use php in "enterprise" applications everyday. phplib provides me with a templating class so that content and programming are completely separated, a OO html widgets class so that form elements are generated and automatically validated with client side javascript, a database abstraction class (switching from a prototype in mysql to the application with MS-SQL db is no problem), and fine tuned session and authentication classes.

Even php as a language itself works well in an enterprise context: c like syntax means training new new graduates is easy, OO (as of version 4, at any rate) is powerful, and the built in libraries are comparable, if not superior, to other scripting languages (regex and string/array/stack/list manipulation, everybody's got, but flash generation, pdf interaction, SOAP, xml-rpc... with php the riches go on and on).

Finally, I find mod_php to be very comparable in speed of execution to mod_perl (benchmarks here)with superior readability. All this to say: opinions are fine, but back them up with real world experience and real data. If you have had experience with php in an enterprise level application where the language or runtime failed to meet your needs, please share with /.! Otherwise, please don't run down my web-app language of choice with hearsay simply because you learned something else first...

Have a peek at http://www.chamas.com/hello_world.html. This is a comprehensive benchmarking site for all types of backkends for webservers and includes mod_perl and jserv/servlets.

According to the site your servlets will be running about 10 times slower than perl.

Firstly, PerlScript-ASP will flunk any performance test you give it right now because it's practically at the fork() level of functionality (new perl interpreter per request). Trust me on this one.

For some more interesting breakdowns of different scripting model overheads see Hello World Benchmarks. The aim of those test is not about real world applications, but about the overhead of starting the interpreter. Basically, mod_perl, PHP4 and ASP/VBScript all come out around the same level performance-wise. However it's worth bearing in mind that mod_perl is a _lot_ more than just a CGI scripting API - it's access to the entire Apache server architecture - something the other engines just don't give you.

http://www.chamas.com/hello_world.html



That web page is maintained by Joshua Chamas, and originated in some discussions that began on the mod_perl mailing list. A page related to it was featured on Slashdot a month or two ago.

I'm by no means an expert, but here's my very rudimentary understanding of the situation:

Most CPU cycles spent on CGI stuff are not so much spent on crunching the data as they are moving the data around and communicating with the webserver. For this reason, things like PHP, ASP, mod_perl, and custom written Apache modules have been developed to plug directly into the webserver's guts. This avoids the overhead associated with forking a separate process to do the computations, opening a pipe to communicate between the webserver & the CGI process and the general cost of loading another program.

However, if you've got a webpage that needs to do something like compute Pi to the 10,000th digit every time a user hits it, then the CGI overhead will be dwarfed by the computing power required to generate the page. For this, it would make more sense to write an Apache module in C.


Why not write everything as a C Apache module?

Because writing a Perl Apache module isn't significantly slower, although it is significantly easier, more expedient, has better database connectivity and is less painful to maintain. But then again, I'm a professional mod_perl programmer, so maybe I'm a bit biased. :)