Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of pharkins@gmail.com designates
 209.85.212.49 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=raihZG4lZKN6uEBdXYEHHO+yfilRPSGUQUBo9WzObcUmYUFtzfdy7S/NItMyhOL5m/
         n4hJCs8H7lewflxnNm0u3QBC+/37q3bsaqtdqj6lMWXLfhYBWapsyeAzl7Ic330ArpMf
         KQwB6HFdOff+GCWh6uu5XJhg4kYFjlpfE24jo=
MIME-Version: 1.0
Sender: pharkins@gmail.com
In-Reply-To: <4E000948.15516.6D8595@randolf.modperl.pl>
References: <BANLkTim2Lwhbr=Q_nsJxH0jmwgZweoA6uA@mail.gmail.com>
	<4DFBE32B.30628.BC197C@randolf.modperl.pl>
	<BANLkTi=d8NtThusrvrp9u7L0pq_fdhK8Dw@mail.gmail.com>
	<4E000948.15516.6D8595@randolf.modperl.pl>
Date: Tue, 21 Jun 2011 12:09:02 -0400
Message-ID: <BANLkTimGZamMiuzpH18Ud=KxuDj1xELonw@mail.gmail.com>
Subject: Re: How do you use mod_perl for your web application?
From: Perrin Harkins <perrin@elem.com>
To: randolf@modperl.pl
Cc: mod_perl list <modperl@perl.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 20, 2011 at 11:00 PM, Randolf Richardson <randolf@modperl.pl> w=
rote:
>=A0I 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.

> =A0 =A0 =A0 =A0One argument that I see come up a lot is "it hasn't been u=
pdated 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. =A0They just save you some
>> repetitive code for simple things.
>
> =A0 =A0 =A0 =A0Yes, but I'm wondering if the caching being shut off in th=
e 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