This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Perl

LAMP vs. LAMP

By Keith Winston on August 22, 2006 (8:00:00 AM)

Share    Print    Comments   

Perl and PHP are two widely used languages for building dynamic Web sites. They make up two thirds of the "P" in the Linux, Apache, MySQL, Perl/PHP/Python (LAMP) stack. How does their performance, using mod_perl and mod_php, compare for everyday Web programming? I attempted to find out.

My test bed was a reasonable facsimile of what one would find on a Web host; specifically, a Compaq ProLiant DL380 server with the following specifications and software:

700Mhz Pentium III
1G RAM
Red Hat Enterprise Linux 3
Apache 2.0.46
MySQL 3.23.58
Perl 5.8.0
PHP 4.3.2

For testing, I created two programs in Perl and two in PHP that produced identical results using logic as similar as I could make them. One program generates HTML, and the second reads and updates a MySQL database.

For the HTML generation test, each program counts from 1 to 1,024 and writes a line of HTML to the screen. I choose five different run loads:

1 HTTP request

100 HTTP requests (serially)
100 HTTP requests (10 concurrently)
1000 HTTP requests (serially)
1000 HTTP requests (10 concurrently)

For the MySQL test, each program runs a single HTTP request that reads and updates 5,000 records in a table. To communicate with MySQL, I used the standard PHP interface and Perl DBI. Here is the structure of the test table:

+----------+----------+------+-----+---------+----------------+
| Field    | Type     | Null | Key | Default | Extra          |
+----------+----------+------+-----+---------+----------------+
| id       | int(11)  |      | PRI | NULL    | auto_increment |
| junktext | char(30) | YES  |     | NULL    |                |
+----------+----------+------+-----+---------+----------------+

Each of the 5,000 records was initialized as follows:

+-------+--------------------------------+
| id    | junktext                       |
+-------+--------------------------------+
| 1     | XXXXXXXXX0XXXXXXXXX0XXXXXXXXX0 |
+-------+--------------------------------+

The programs read each record from the table, convert the junktext column to lower case, then write it back. The goal was to test the database drivers and overhead in Perl and PHP.

I performed no tuning on any component of the LAMP stack as delivered from Red Hat. In a hosted environment, being able to change system components is a rare luxury. For your reading pleasure, I present the Perl HTML test code, Perl MySQL test code, PHP HTML test code, and PHP MySQL test code.

Results

HTML I ran each script using the ApacheBench program (version 2.0.40) -- part of the standard Apache package -- which measures the time for each HTTP request to be processed and reports totals and averages. I ran each benchmark three times and took the mean results. All tests were run on an internal network, where both client and server were isolated from the vagaries of the Internet.

As a baseline, I decided to include the execution of each Perl program as a regular Common Gateway Interface (CGI) program. CGI was one of the first methods of creating dynamic Web content. There are still many CGI programs working their magic on the Web. The problem with CGI is that it forks a new process and loads a copy of the Perl interpreter for each request, which uses gobs of memory. Mod_perl includes the Perl interpreter within Apache. Both mod_perl and mod_php run inside the Apache process that is handling the page, providing more efficient execution.

Following are the results of the Perl CGI, mod_perl, and mod_php tests. The number after HTTP in column one indicates the number of requests for that test. A number followed by a c indicates that 10 concurrent requests were run for that test. All times are in seconds (lower is better).

HTML generation tests
  CGI mod_perl mod_php
HTTP-1 0.1607 0.2392 0.1711
HTTP-100 16.6229 2.4346 1.6607
HTTP-100c 16.4683 1.8337 1.5694
HTTP-1000 160.8190 16.2288 16.6460
HTTP-1000c 161.1753 17.2127 15.6850

MySQL test
  CGI mod_perl mod_php
MySQL-rw 1.8157 1.4807 1.2189

Conclusions

MySQL I need to hedge my observations somewhat, because using object-oriented features of either language, adding third party modules or sessions to the mix, or using a different type of storage could alter the outcome.

That said, the results of these tests show that for many common Web programming tasks, PHP (mod_php) has a slight performance edge over Perl (mod_perl), based on the majority of the HTML generation tests. In the MySQL test, PHP also edged out Perl. I suspect the MySQL results are a reflection of the database drivers more than the interpreters.

Both mod_perl and mod_php have an enormous performance advantage over standard CGI, as expected. Standard CGI not only doesn't scale very well, but gains no advantage from concurrency. Under load, it could bring a server to its knees quickly.

There are interesting and unique things about mod_perl. First, since it compiles a Perl program and keeps it cached in memory for subsequent uses, it performs better as the load goes up. For example, I ran the tests back-to-back, and the second and third tests were always faster than the first. If I waited some time between tests, the cache appeared to be cleared and mod_perl had to compile the program again. The numbers above are from back-to-back tests.

Mod_perl offers the ability to embed Perl code in the Apache configuration file. This provides more options for dynamic server configuration. PHP does not have an equivalent feature.

PHP provided consistent performance no matter how I tested it. It was designed from the start as a dynamic Web language, and excels in that role.

For tweakers, there are a number of ways to increase Perl and PHP performance with Apache. For Perl, there is the FastCGI module, and there are several proprietary and free (as in beer), and open source PHP cache accelerators. These are advanced options and require additional work to set up.

No-lose scenario

Both Perl and PHP are robust and powerful languages for creating Web applications. For small and medium-sized applications, the difference in their performance would be hard to notice. Extrapolating these results to high-traffic applications is not a good idea, because too many other factors come into play in those scenarios.

Bottom line: Whether you opt for Perl or PHP, you win.

Share    Print    Comments   

Comments

on LAMP vs. LAMP

Note: Comments are owned by the poster. We are not responsible for their content.

what about a compiled cgi programm

Posted by: Anonymous Coward on August 23, 2006 02:22 AM
of course perl-cgi is not suited for high performance sites. This should not surprise any expert. What about compiled cgi, i.e. in C++?

#

Or Complied Java?

Posted by: Anonymous Coward on August 23, 2006 07:32 AM
Ok Linux thing most of the time still. gcj to covert the web form to a native binary.

Normally don't use C or C++ in web development not cross platform enough. jar to native binary is nice.

#

Re:Debugging?

Posted by: AnomalousUser on August 24, 2006 09:30 AM
Surely most web development is in-house. Why would you want it to be cross-platform? You are not trying to target a mass audience, just your own web-server environment and your next few server upgrades. I also question your claim that C is `not cross-platform enough'! Expecially since your counter-example is Java! Put it another way. C is plenty cross-platform enough that thousands of cross-platform applications use it. How is server-side web development somehow special?

#

These results are not valid

Posted by: ChaseVenters on August 23, 2006 02:47 AM
As someone who uses mod_perl professionally, I'm disappointed to say that your testing methodology is all wrong. Though I doubt that you've done so intentionally, you have used mod_perl in a way that is (a) not recommended and (b) does not take advantage of mod_perl's performance potential.

The way you have written this test:

1. Uses CGI.pm instead of Apache API calls
2. Uses tied STDOUT printing instead of mod_perl print calls
3. Uses Registry instead of a handler subroutine, which is not only the recommended way of coding new applications but is also much faster

Furthermore, you have not properly used prepared statements in your usage of DBI during the MySQL testing.

Please correct these errors and re-test; your results are completely invalid.

#

Re:These results are not valid

Posted by: Anonymous Coward on August 23, 2006 04:27 AM
I was thinking the same thing. I would be interested to see what the results look like after those changes are made...

#

Re:These results are not valid

Posted by: Anonymous Coward on August 23, 2006 06:10 AM
I would have to agree, for the first two points, why not replace the perl HTML code with this:
<tt>#!/usr/bin/perl

 
print q{
<html>
<head>
<title>HTML test</title>
<body>

 
<h4>HTML test</h4>
<p>
};

 
for $i (1..1024) {
    print "$i<br>";
}

 
print q{
<b>done!</b></p>

 
</body>
</html>
};</tt>
Then you'd be getting a pretty straight-forward comparison.

#

Re:These results are not valid

Posted by: Anonymous Coward on August 23, 2006 09:50 AM
Also, I think the MPM used could throw significant differences... PHP REQUIRES a prefork model, while mod_perl could use a worker model (theoretically, better for high concurrency)<nobr> <wbr></nobr>...

#

Re:These results are not valid

Posted by: walt-sjc on August 24, 2006 01:53 AM
RHEL3 is also Very old. Look at the versions of everything then check at RHEL4 (which is still fairly old) or other more current distro.

It's like performance testing a 1975 ford against a 1975 chevy.

#

Yes but...

Posted by: Anonymous Coward on August 23, 2006 04:26 AM
...how does it compare to<nobr> <wbr></nobr>.NET?

#

Re:Yes but...

Posted by: Anonymous Coward on August 24, 2006 02:47 AM
Uhm, who gives a shit about<nobr> <wbr></nobr>.NET? Get your stupid M$ ass out of here, boy!

#

Re:Yes but...

Posted by: Anonymous Coward on August 24, 2006 10:28 PM
Ha come on....
We all know that M$ is proprietary (ouf... mispelling)
but I think it could be cool to compare it to<nobr> <wbr></nobr>.NET or ASP... Just see how does php/perl perform against the others.

#

some corrections about mod_perl

Posted by: Anonymous Coward on August 23, 2006 11:56 AM
The caching of compiled code is a base feature of Perl itself, not something mod_perl adds. To make a fair test, I'd suggest using a code cache for PHP as well, and using the normal steps that a performance-oriented user would take with mod_perl, i.e. write a handler rather than a Registry script, use Apache::Request rather than CGI.pm, etc. Also, the FastCGI module for Perl is an alternative to mod_perl which is for use with FastCGI. It is not an accelerator for mod_perl.

#

Just assign a job to Perl and PHP

Posted by: Anonymous Coward on August 23, 2006 02:23 PM
I am not a good programmer - but my logic in this case says: use hook or crook to get the job done.

I mean:

1. Create a comprehensive list of possible web programming requirements. (Please excuse my English). E.g. Connect to database - execute query and disconnect from database, print HTML page, print XML page, open and close files in the background, etc.

2. Assign a job to Perl and PHP! That is, configure both languages in the best way it is possible to configure it - taking advantage of all nuances of each language.

3. Write an optimized query - possibly ask people at IRC to help you comment on the optimality of your code.

4. Get 2 result sets:
a) By not following good/best practices - just try to run it as fast as you can. E.g. omitting errors and warning and die, etc.
b) Use good/best practices.

#

Full bulshit

Posted by: Anonymous Coward on August 23, 2006 02:18 PM
This is not test! This is bulshit.
You don`t know what is FastCGI.

#

Just assign a job to Perl and PHP

Posted by: Anonymous Coward on August 23, 2006 02:50 PM
Sorry, I replied to the wrong post instead of the article.

Here's the message:

I am not a good programmer - but my logic in this case says: use hook or crook to get the job done.

I mean:

1. Create a comprehensive list of possible web programming requirements. (Please excuse my English). E.g. Connect to database - execute query and disconnect from database, print HTML page, print XML page, open and close files in the background, etc.

2. Assign a job to Perl and PHP! That is, configure both languages in the best way it is possible to configure it - taking advantage of all nuances of each language.

3. Write an optimized query - possibly ask people at IRC to help you comment on the optimality of your code.

4. Get 2 result sets:
a) By not following good/best practices - just try to run it as fast as you can. E.g. omitting errors and warning and die, etc.
b) Use good/best practices.

#

Perl is not an option for many

Posted by: Anonymous Coward on August 24, 2006 12:11 AM
No matter where and what the performance advantage is, PHP will be the choice for many. Perl has number of advantages over PHP, but it is not easy to learn, even for developers with experience in other languages.

What I see as a good side of Perl is that much more functionality is built in by default. Furthermore, there are many modules written in Perl, that are more portable. That is very important when the application resides on the server owned by someone else, and when developer depends on someone else to install (or refuse to install) the modules.

The battle between execution speed and development speed has been won long ago. The clear winner is development speed.

I don't expect mod_perl to replace mod_php.

DG

#

Re:Perl is not an option for many

Posted by: Anonymous Coward on August 24, 2006 01:04 PM
The biggets gotcha here is persistent database connections with mysql. PHP used to enable this feature by default, however perl does not and you will need to enable Apache::DBI from CPAN into your apache config.

#

What about....

Posted by: Anonymous Coward on August 24, 2006 11:56 PM
mod_python? mod_ruby (LAMR)?

#

Comparaison with others

Posted by: Anonymous Coward on August 28, 2006 09:33 AM
Although I have no intention to use<nobr> <wbr></nobr>.NET, I agree with the guy above that performence comparaison would be interresting.

I would also wish to see Ruby,Rails comparaison with different environment. Apache FastCGI and mod_ruby, mongrel, lighttpd, etc.

#

Php5

Posted by: Anonymous Coward on August 28, 2006 09:50 PM
Nobody benchmarks with PHP 4 anymore. PHP 5 has been out for almost 2 years now. Next time try using current versions for benchmarking instead of 5 year old versions.

#

LAMP is not PERL

Posted by: Anonymous Coward on August 28, 2006 09:55 PM
Just for the record, the acronym LAMP was created to stand for Linux, Apache, MySQL and PHP in a forum around 1998. It wasn't until recently when O'Reillys wanted to sell more books that they started saying the P stood for Python and Perl as well.

The original reason why PHP was part of LAMP is because it had built in MySQL support and Apache came with the PHP module and all Linux distros come with Apache.

Little history lesson for those who insist on being tools of O'reillys.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya