LAMP vs. LAMP
Anton Gorlov
LAMP vs. LAMP
Tuesday August 22, 2006 (05:00 PM GMT)
By: Keith Winston nb8...@gmail.com
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.
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
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
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.
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.
С уважением. Anton aka Stalker
np: silence ( Winamp ушел в Партизаны ;-)
Linux Registered User #386476
[#*TEAM:*#] [#_Злой СисОп_#] [*Heavy Metal!*] [*_Усачи_*]