perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Octavian Rasnita" <>
Subject Re: How do you use mod_perl for your web application?
Date Mon, 27 Jun 2011 05:55:07 GMT
From: "Randolf Richardson" <>
>> On Fri, Jun 24, 2011 at 3:00 PM, Phil Van <> wrote:
>> > Interesting.... those are mod_fcgid + CGI, compared to plain
>> > Apache + mod_perl + libapeq ?
>> There are a number of modules like CGI and libapreq that run in
>> multiple environments.  My benchmark was a Catalyst app that just
>> returned about 30K of HTML.
> [sNip]
> I believe Catalyst depends on DBIx::Class, which also tries to turn
> off the connection caching features provided by Apache::DBI (if I'm
> recalling correctly) -- if this is true, then it could certainly help
> to explain the lesser performance in a ModPerl environment.

Catalyst doesn't depend on DBIx::Class.
DBIx::Class just does its own persistent connection and this is why it 
doesn't need Apache::DBI.

The performance is always lower for high-level programs than for low-level 
Catalyst, DBIx::Class, Template-Toolkit, HTML::FormFu are high level modules 
which decrease the performance, but increase very much the productivity, so 
it depends on what is most important for you.

If somebody needs to squeeze every millisecond from an application without 
scaling it by adding more and more servers, mod_perl handlers is the way to 
On the other hand, if somebody needs to create many applications that should 
be easy to maintain, or if the performance is not so important - you don't 
need to handle millions requests every day, then a higher level program is 
the way to go - a pre-made CMS, or blog, or wiki, or if they are too 
restrictive, a web framework + ORM + templating system + form processor.

> To be fair, I think it would be important to run benchmarks against
> a number of different products (some with database dependencies, some
> without, etc.), and make sure the same peformance enhancing features
> (such as database connection handle caching) are functioning (or not
> functioning) across the different environments (e.g., mod_fcgid,
> mod_perl2, etc.).

Such a benchmark is usually the way of convincing the beginners, because the 
speed difference is usually the most simple and easy to understand 
difference between 2 similar programs.
But as I said, a lowe level program is always faster than a higher level one 
(or at least in general, if both of them are done right).

DBIx::Class uses DBI and many other modules which make programming much 
easier, so the programmer doesn't need to reinvent the wheel and concatenate 
strings for creating SQL queries. A templating system also is more readable 
and easier to understand than a big string with the entire page content 
which has Perl variables inside, a form processor is easier to maintain and 
create than a custom-created system of filtering, validating, applying 
constraints and other things for the input data, and a web framework is also 
much easier to use and maintain than doing a custom URL dispatching, 
character encoding, authentication, authorization, and many other things.

Yes, as usually, the lower-level programs are more flexible and offer much 
more possibilities, but with a higher effort, and usually this effort is not 
necessary because most applications are not very complex.

Catalyst can be used very fine with mod_perl, but yes, I heard very many 
recommendations (and not only from Catalyst users) to use fastcgi and not 

I use mod_perl with Catalyst because I found it more easy to use for my 
needs, but I do understand their opinions.

Ideally, a Perl application should not need C-based modules, should not 
require a certain web server nor a certain database, and it should be 
portable under all operating systems.
It would be very fine to not depend on Perl either, but this may be harder 
to do. :-)

FastCGI can be used under more web servers, and this may be very important 
for those who need to deploy their applications on some VPS or on the cloud, 
where they might not have very many resources available, and so they may 
want to use a web server that consumes less resources than Apache.


View raw message