From: "Randolf Richardson" <rand...@modperl.pl>
On Fri, Jun 24, 2011 at 3:00 PM, Phil Van <pv2...@gmail.com> 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
ones.
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
go.
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
mod_perl.
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.
Octavian
