perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Perrin Harkins <>
Subject Re: How do you use mod_perl for your web application?
Date Tue, 21 Jun 2011 16:09:02 GMT
On Mon, Jun 20, 2011 at 11:00 PM, Randolf Richardson <> wrote:
> I have encountered some people
> (not just in the DBIx::Class community) who have told me things like
> "you should be using FastCGI instead," or "you're crazy to not run
> mod_perl behind a proxy," etc.

Well, this is a sidetrack, but the proxy advice is just about
separating the processes delivering bytes to browsers from the ones
doing the perl work.  Proxies are not the only way to achieve it, but
the general concept is sound.  It cuts down on the number of processes
needed to server a given number of clients.

>        One argument that I see come up a lot is "it hasn't been updated in
> years" as if regular updates are an important measurement.

Besides the pointlessness of this criticism, it's also not true.
There have been recent updates to mod_perl, httpd, and perl.  I doubt
that mod_fastcgi is getting a lot more updates, and I doubt that the
alternative servers for FastCGI or PSGI are getting a lot more updates
than the combined total of httpd (which is mod_perl's server) and its
modules.  When you use mod_perl, you get a huge number of people
maintaining and testing all the components that come together in the
form of apache modules like mod_deflate and mod_ssl.

>> You'll always get better performance from straight DBI than from ORMs
>> like DBIx::Class or Rose::DB::Object.  They just save you some
>> repetitive code for simple things.
>        Yes, but I'm wondering if the caching being shut off in the ORM
> might be a major contributing factor as well because the difference
> is very noticeable (plus, for certain things I see a lot of extra SQL
> queries in the logs when I'm using the ORM), although it also wasn't
> performing poorly before switching to DBI (which I think is an
> excellent testimonial for mod_perl2's performance).

ORMs just can't be as intelligent about which data to retrieve as
custom code can.  SQL is too powerful a tool to be fully captured in
the limited APIs they have.  They are very useful for cutting down on
boilerplate code though.

- Perrin

View raw message