How do you use mod_perl for your web application?

I'm interested in hearing about what application frameworks (Catalyst,
CGI::App, Mojolicious) are used here with mod_perl. Given the number
of emerging Perl based webservers on CPAN (in addition to Nginx,
lighty, etc), it seems like there are many more Perl web application
and webservers out there now than there were five years ago.

I'll start. I have a couple of Apache::Dispatch based applications I
wrote. I also work on an Apache::ASP large codebase, and a couple of
different Catalyst based systems. All are running on mod_perl 2.0.4
in production (the ops haven't upgraded to 2.0.5 yet).

If I were to migrate, I would probably try out something like
Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never
been an issue to date, but I have Perlbal doing connection handling as
a reverse proxy.

Re: How do you use mod_perl for your web application?

On Jun 15, 2011, at 9:01 PM, Fred Moyer wrote:

> I'll start. I have a couple of Apache::Dispatch based applications I
> wrote. I also work on an Apache::ASP large codebase, and a couple of
> different Catalyst based systems. All are running on mod_perl 2.0.4
> in production (the ops haven't upgraded to 2.0.5 yet).

I use Apache 2 as a reverse proxy for a bunch of Starman-powered Plack =
apps. And I have a Bricolage install on mod_perl2.

> If I were to migrate, I would probably try out something like
> Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never
> been an issue to date, but I have Perlbal doing connection handling as
> a reverse proxy.

PGXN, which runs on Starman, will be moving to a PostgreSQL community =
server. I think they use Varnish for reverse proxying.

Best,

David

Re: How do you use mod_perl for your web application?

On 06/16/2011 12:01 AM, Fred Moyer wrote:

> I'll start. I have a couple of Apache::Dispatch based applications I
> wrote. I also work on an Apache::ASP large codebase, and a couple of
> different Catalyst based systems. All are running on mod_perl 2.0.4
> in production (the ops haven't upgraded to 2.0.5 yet).

We use CGI::Application on mod_perl 1.31 (I know, I know) with Apache 2
as a reverse proxy.

> If I were to migrate, I would probably try out something like
> Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never
> been an issue to date, but I have Perlbal doing connection handling as
> a reverse proxy.

We're looking at migrating to PSGI. We actually plan to do a full
evaluation of backends (mod_perl2 vs Starman) and proxies (varnish,
lighttpd, nginx, apache2, perlbal) with SSL thrown in the mix too (some
proxies don't do SSL so we'll look at doing proxy + pound)

--
Michael Peters
Plus Three, LP

Re: How do you use mod_perl for your web application?

> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl.

Currently, I use plain mod_perl2 2.0.4 with apache2 for a project about 10k
LOC on the web side and about 32k application's LOC.

I would like to know a better framework to use in a very specific case: web
side and application are separated in different virtual servers. I see no gain
in using Mojolicious in my case.
--
Anton Petrusevich

Re: How do you use mod_perl for your web application?

On Thu, Jun 16, 2011 at 12:01 AM, Fred Moyer wrote:
> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl.

Mason 1.x on mod_perl 1.x and apache 1.x, baby!

- Perrin

Re: How do you use mod_perl for your web application?

On Jun 16, 2011, at 12:14 PM, Perrin Harkins wrote:

> On Thu, Jun 16, 2011 at 12:01 AM, Fred Moyer =
wrote:
>> I'm interested in hearing about what application frameworks =
(Catalyst,
>> CGI::App, Mojolicious) are used here with mod_perl.
>=20
> Mason 1.x on mod_perl 1.x and apache 1.x, baby!

Whatever old man!

David

Re: How do you use mod_perl for your web application?

On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler wrote:
> Whatever old man!

I know, it's just a reality of working on applications that have been
around for years. These tools are so reliable that they tend to stick
around. If I started something new I would probably use Plack, since
I've enjoyed using similar stuff in Python.

- Perrin

Re: How do you use mod_perl for your web application?

On Thu, Jun 16, 2011 at 1:13 PM, Perrin Harkins wrote:
> On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler =
wrote:
>> Whatever old man!
>
> I know, it's just a reality of working on applications that have been
> around for years. =A0These tools are so reliable that they tend to stick
> around. =A0If I started something new I would probably use Plack, since
> I've enjoyed using similar stuff in Python.

Maybe I'm not completely grokking how people are starting new projects
using Plack, but it seems like the way to go is to not use Plack
itself to write the code, but to use one of the many web frameworks
(Mason2, Catalyst, Mojolicious) and then use Plack to specify what
webserver is used. Plack is just middleware.

There is a Mason handler for Plack, so it almost seems like you could
migrate your existing application to the Plack middleware stack while
changing little in your Mason codebase.

I see the role of mod_perl2 going forward as not something that
applications are written on, but something that webserver middleware
interfaces with.

Re: How do you use mod_perl for your web application?

I had 8-9 apps running as custom mp2 modules (not really in any
framework.) I did a few things in Catalyst, but it never really lit
my candle. Perlbal for reverse proxy. I used Postgres a lot, but
eventually realized that sqlite3 was good enough for what I was doing
most of the time.

Of late, I've been wanting to go to PSGI or node.js, but I haven't
taken the plunge yet. Many of my mod_perl apps relied on client-side
PKI and SSL renegotiation, which I don't think can be done in PSGI,
(or at least not well) and mod_perl really shines by having hooks for
all phases of request handling.



On Thu, Jun 16, 2011 at 12:01 AM, Fred Moyer wrote=
:
> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl. =A0Given the number
> of emerging Perl based webservers on CPAN (in addition to Nginx,
> lighty, etc), it seems like there are many more Perl web application
> and webservers out there now than there were five years ago.
>
> I'll start. =A0I have a couple of Apache::Dispatch based applications I
> wrote. =A0I also work on an Apache::ASP large codebase, and a couple of
> different Catalyst based systems. =A0All are running on mod_perl 2.0.4
> in production (the ops haven't upgraded to 2.0.5 yet).
>
> If I were to migrate, I would probably try out something like
> Mojolicious on Plack on mod_perl2. =A0Performance of mod_perl2 has never
> been an issue to date, but I have Perlbal doing connection handling as
> a reverse proxy.
>

Re: How do you use mod_perl for your web application?

On Thu, Jun 16, 2011 at 1:19 PM, Daniel Risacher wrot=
e:
> Of late, I've been wanting to go to PSGI or node.js, but I haven't
> taken the plunge yet. =A0Many of my mod_perl apps relied on client-side
> PKI and SSL renegotiation, which I don't think can be done in PSGI,
> (or at least not well) and mod_perl really shines by having hooks for
> all phases of request handling.

Having support for these request phases is definitely something that
middleware authors should keep in mind when looking to support
mod_perl2 well. I don't think Plack does this right now.

Re: How do you use mod_perl for your web application?

On 06/16/2011 04:18 PM, Fred Moyer wrote:

> Maybe I'm not completely grokking how people are starting new projects
> using Plack, but it seems like the way to go is to not use Plack
> itself to write the code, but to use one of the many web frameworks
> (Mason2, Catalyst, Mojolicious) and then use Plack to specify what
> webserver is used. Plack is just middleware.

Yes, but lots of people are using Plack to refer to the Plack family of
stuff. Mainly the PSGI spec, the middleware and possibly one of the new
Plack/PSGI oriented servers (like Starman).

> I see the role of mod_perl2 going forward as not something that
> applications are written on, but something that webserver middleware
> interfaces with.

Yeah, that's what I see too. I'd like to see the performance of Starman
vs mod_perl for normal applications (that don't need to do anything
fancy with Apache). If it's anywhere close to mod_perl than I suspect
lots of people would use it instead since it's much easier to setup and
also much easier to package with your app since it's just a CPAN module.
Would be nice to through FastCGI into that benchmark too.

--
Michael Peters
Plus Three, LP

Re: How do you use mod_perl for your web application?

----- Original Message ----

> From: Fred Moyer
> To: Perrin Harkins
> Cc: David E. Wheeler ; mod_perl list
>
> Sent: Thu, June 16, 2011 4:18:17 PM
> Subject: Re: How do you use mod_perl for your web application?
>
> On Thu, Jun 16, 2011 at 1:13 PM, Perrin Harkins wrote:
> > On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler
>wrote:
> >> Whatever old man!
> >
> > I know, it's just a reality of working on applications that have been
> > around for years. These tools are so reliable that they tend to stick
> > around. If I started something new I would probably use Plack, since
> > I've enjoyed using similar stuff in Python.
>
> Maybe I'm not completely grokking how people are starting new projects
> using Plack, but it seems like the way to go is to not use Plack
> itself to write the code, but to use one of the many web frameworks
> (Mason2, Catalyst, Mojolicious) and then use Plack to specify what
> webserver is used. Plack is just middleware.
>
> There is a Mason handler for Plack, so it almost seems like you could
> migrate your existing application to the Plack middleware stack while
> changing little in your Mason codebase.
>
> I see the role of mod_perl2 going forward as not something that
> applications are written on, but something that webserver middleware
> interfaces with.

Sigh. The big win with mod_perl2 is you get to interface with the rest
of the C modules for httpd, often via subrequests. At the ASF we've
been running mod_perl2 as our frontline mailserver for over 5y, and recently
I wrote an ASF-wide CMS with it that's gaining more and more users as
time goes on, in under 5K LOC. Haven't seen the need for app frameworks
because most of my code is mod_perl2 specific- it just won't work in any
other webserver.

Re: How do you use mod_perl for your web application?

> ----- Original Message ----
>
>> From: Fred Moyer
>> To: Perrin Harkins
>> Cc: David E. Wheeler ; mod_perl list
>>
>> Sent: Thu, June 16, 2011 4:18:17 PM
>> Subject: Re: How do you use mod_perl for your web application?
>>
>> On Thu, Jun 16, 2011 at 1:13 PM, Perrin Harkins wrote:
>> > On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler
>>wrote:
>> >> Whatever old man!
>> >
>> > I know, it's just a reality of working on applications that have been
>> > around for years. These tools are so reliable that they tend to stick
>> > around. If I started something new I would probably use Plack, since
>> > I've enjoyed using similar stuff in Python.
>>
>> Maybe I'm not completely grokking how people are starting new projects
>> using Plack, but it seems like the way to go is to not use Plack
>> itself to write the code, but to use one of the many web frameworks
>> (Mason2, Catalyst, Mojolicious) and then use Plack to specify what
>> webserver is used. Plack is just middleware.
>>
>> There is a Mason handler for Plack, so it almost seems like you could
>> migrate your existing application to the Plack middleware stack while
>> changing little in your Mason codebase.
>>
>> I see the role of mod_perl2 going forward as not something that
>> applications are written on, but something that webserver middleware
>> interfaces with.
>
> Sigh. The big win with mod_perl2 is you get to interface with the rest
> of the C modules for httpd, often via subrequests. At the ASF we've
> been running mod_perl2 as our frontline mailserver for over 5y, and recently
> I wrote an ASF-wide CMS with it that's gaining more and more users as
> time goes on, in under 5K LOC. Haven't seen the need for app frameworks
> because most of my code is mod_perl2 specific- it just won't work in any
> other webserver.

Agreed with this ....

I've been looking around at all these discussions the situation I'm in
is probably more complex than writing a single application I manage a
large infastructure for a large scientific institute with a small core
webteam - and upwards of 200 developers. So my approach to development
is probably considerably different to some of the projects here.

Currently we are migrating our website to a new "mod_perl" backed
system. It has many requirements so our framework (Developed in house)
has to be compact, easy, flexible, and easily extensible, but at the
same time give good diagnostics and stop bad code being submitted.

The system is a mixture of:

* mod_perl handlers to perform routing, mapping URL spaces to
perl modules; to handle temporary files; improve error reporting;
handle user identity etc; built in caching, optimisation of images/
js/css;
* mod_perl output filters to handle page decorating;
* javascript/css libraries tied into the system;
* integrated support for AJAX;
* a series of modules which handle Components (parts of pages which
can be included into static HTML/dynamically generated HTML);
and Actions (web pages, JSON/XML documents etc)
* an SVN based sandbox/dev/staging/production system to pubish
code, and check quality tool to force good HTML, Javascript;
* tools to monitor changes, etc
* ability to write applications as either CGI scripts, mod_perl
(using registry) [but both are frowned on], Ruby, PHP, Java,
HTML/JavaScript and
still have the benefits of the decoration and component system
(Ruby, PHP, Java etc just produce raw HTML containing component
instructions)

e.g.
http://www.sanger.ac.uk/resources/databases/tiffin/table.jsp ?col=3

Is a JSP wrapped using Perl to look like the rest of the site...

In other projects I combine it with PHP to handle a lot of the
initial set up - parsing cookies for users etc and populating
variables that other applications can use;

It has a few more lines of code than yours - but the core of the
system is quite compact - it's just the fluff and added features
which make it longer... (plus getting the code through perl::critic!)





--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

Re: How do you use mod_perl for your web application?

On Thu, Jun 16, 2011 at 4:18 PM, Fred Moyer wrote:
> Maybe I'm not completely grokking how people are starting new projects
> using Plack, but it seems like the way to go is to not use Plack
> itself to write the code, but to use one of the many web frameworks
> (Mason2, Catalyst, Mojolicious) and then use Plack to specify what
> webserver is used. =A0Plack is just middleware.

I'm just saying Plack looks fun. Maybe I miss the days of writing OO
mod_perl handlers. That was fun.

> There is a Mason handler for Plack, so it almost seems like you could
> migrate your existing application to the Plack middleware stack while
> changing little in your Mason codebase.

It's clear that you haven't seen this Mason codebase ;)

- Perrin

Re: How do you use mod_perl for your web application?

On Thu, Jun 16, 2011 at 1:30 PM, Joe Schaefer wrot=
e:
> Sigh. =A0The big win with mod_perl2 is you get to interface with the rest
> of the C modules for httpd, often via subrequests. =A0At the ASF we've
> been running mod_perl2 as our frontline mailserver for over 5y

This is Apache2::Qpsmtpd right? Nice module.

> , and recently
> I wrote an ASF-wide CMS with it that's gaining more and more users as
> time goes on, in under 5K LOC. =A0Haven't seen the need for app framework=
s
> because most of my code is mod_perl2 specific- it just won't work in any
> other webserver.

I guess I should rephrase what I said earlier; I don't see use of
mod_perl2 for web applications going away. I see the usage pattern
for Perl based web applications that use frameworks like Catalyst et
al becoming one where there is less usage of tightly coupled modules
such as Apache::Session and Apache::DBI.

The ability to interface with the httpd C modules is a big win that I
don't think a lot of users appreciate until their application gets big
enough to cause pain. Output compression is one area I've seen people
struggle with in Perl land, and write elaborate hacks into their
Catalyst application, when they could do the same thing in httpd.conf
with 'Include conf/deflate.conf' and just stuff all the mod_deflate
directives in that file.

Re: How do you use mod_perl for your web application?

On Thu, Jun 16, 2011 at 1:26 PM, Michael Peters wrote:
> I'd like to see the performance of Starman vs
> mod_perl for normal applications (that don't need to do anything fancy with
> Apache). If it's anywhere close to mod_perl than I suspect lots of people
> would use it instead since it's much easier to setup and also much easier to
> package with your app since it's just a CPAN module. Would be nice to
> through FastCGI into that benchmark too.

I tweeted @miyagawa to see if he had this benchmark, and if memory
serves mod_perl2 was about 75% the speed of Starman in a hello world
benchmark with an unknown mod_perl2 configuration. I believe the
Starman cpan page has benchmarks vs FastCGI. My takeaway from those
benchmarks was that all of the webservers tested were essentially
equally fast since they were within 25-50% of the performance of each
other with a simple benchmark.

I'm not sold on packaging the webserver with the application though.
I've been moving towards using the webserver (in my case
httpd/mod_perl2) that is installed with the platform. One less thing
for me to worry about, in my case the Centos packagers take care of
that problem for me.

Re: How do you use mod_perl for your web application?

----- Original Message ----
> From: Fred Moyer
> To: Joe Schaefer
> Cc: mod_perl list
> Sent: Thu, June 16, 2011 5:01:49 PM
> Subject: Re: How do you use mod_perl for your web application?
>
> On Thu, Jun 16, 2011 at 1:30 PM, Joe Schaefer wrote:
> > Sigh. The big win with mod_perl2 is you get to interface with the rest
> > of the C modules for httpd, often via subrequests. At the ASF we've
> > been running mod_perl2 as our frontline mailserver for over 5y
>
> This is Apache2::Qpsmtpd right? Nice module.
>
> > , and recently
> > I wrote an ASF-wide CMS with it that's gaining more and more users as
> > time goes on, in under 5K LOC. Haven't seen the need for app frameworks
> > because most of my code is mod_perl2 specific- it just won't work in any
> > other webserver.
>
> I guess I should rephrase what I said earlier; I don't see use of
> mod_perl2 for web applications going away. I see the usage pattern
> for Perl based web applications that use frameworks like Catalyst et
> al becoming one where there is less usage of tightly coupled modules
> such as Apache::Session and Apache::DBI.


To me writing to a generic webserver API is not all that exciting.
Python people love it, but they've never had a proper exposure
to httpd in the first place. Yes it means you gain some portability,
but the downside is that you lose an awful lot of power that comes
from the existing open source module ecosystem for httpd. That's not
easily replaced, no matter what others may say.

> The ability to interface with the httpd C modules is a big win that I
> don't think a lot of users appreciate until their application gets big
> enough to cause pain. Output compression is one area I've seen people
> struggle with in Perl land, and write elaborate hacks into their
> Catalyst application, when they could do the same thing in httpd.conf
> with 'Include conf/deflate.conf' and just stuff all the mod_deflate
> directives in that file.
>

Yup. Content negotiation is another area where people come up with lotsa
sloppy hacks. Just run a subrequest with content-negotiation enabled and
be happy- it just works.

Re: How do you use mod_perl for your web application?

This is a multipart message in MIME format.
--=_alternative 000566FCCA2578B2_=
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Hi Fred,

I use mod_perl on a custom built framework written back in 2005
Performance of mod_perl has never been an issue, internal authenication
and network speed are more issues.
This runs on an intranet and services around 5000 users

Regards
Greg George



From: Fred Moyer
To: mod_perl list
Date: 16/06/2011 02:01 PM
Subject: How do you use mod_perl for your web application?



I'm interested in hearing about what application frameworks (Catalyst,
CGI::App, Mojolicious) are used here with mod_perl. Given the number
of emerging Perl based webservers on CPAN (in addition to Nginx,
lighty, etc), it seems like there are many more Perl web application
and webservers out there now than there were five years ago.

I'll start. I have a couple of Apache::Dispatch based applications I
wrote. I also work on an Apache::ASP large codebase, and a couple of
different Catalyst based systems. All are running on mod_perl 2.0.4
in production (the ops haven't upgraded to 2.0.5 yet).

If I were to migrate, I would probably try out something like
Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never
been an issue to date, but I have Perlbal doing connection handling as
a reverse proxy.

************************************************************ ************************************************************ ************************************************************ ***********
Please consider the environment before printing this e-mail.

This message is intended solely for the individual(s) and entity(s) addressed. It is confidential and may contain legally privileged information. The use, copying or distribution of this
message or any information it contains, by anyone other than the addressee, is prohibited. If you have received this message in error, please notify postmaster@orica.com. The mailbox address
from which this message has been sent is for business mail only. Mail sent to it may be subject to security scanning and delivery on non-business messages sent to this address may not occur.
Thank you.
************************************************************ ************************************************************ ************************************************************ ***********

--=_alternative 000566FCCA2578B2_=
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii"

Hi Fred,



I use mod_perl on a custom
built framework written back in 2005

Performance of mod_perl
has never been an issue, internal authenication and network speed are more
issues.

This runs on an intranet
and services around 5000 users



Regards

Greg George







From:      
 Fred Moyer <fred@redhotpenguin.com>

To:      
 mod_perl list <modperl@perl.apache.org>

Date:      
 16/06/2011 02:01 PM

Subject:    
   How do you use
mod_perl for your web application?

***********************************************************************************************************************************************************************************************

Please consider the environment before printing this e-mail.



This message is intended solely for the individual(s) and entity(s) addressed. It is confidential and may contain legally privileged information. The use, copying or distribution of this 

message or any information it contains, by anyone other than the addressee, is prohibited. If you have received this message in error, please notify postmaster@orica.com. The mailbox address 

from which this message has been sent is for business mail only. Mail sent to it may be subject to security scanning and delivery on non-business messages sent to this address may not occur. 

Thank you.

***********************************************************************************************************************************************************************************************

Re: How do you use mod_perl for your web application?

On Thu, Jun 16, 2011 at 2:01 PM, Fred Moyer wrote:
> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl.

We have a lot of code using CGI::App as well as a mix of in-house
custom frameworks (old legacy stuff that goes back 8 to 10 years).
All our apache/mod_perl servers sit behind three nginx boxes that do
caching, SSL offloading and content compression. 90% of what is
behind the proxies is running apache2/mod_perl2 (stock debian packages
for ease of maintenance), but there is still some apache1.3/mod_perl1
stuff hanging around too.

Some apps run through FastCGI, but the majority are mod_perl content
handlers or Registry scripts.

Cheers,

Cees

Re: How do you use mod_perl for your web application?

Le jeudi 16 juin 2011 à 14:11 -0700, Joe Schaefer a écrit :

>
> To me writing to a generic webserver API is not all that exciting.
> Python people love it, but they've never had a proper exposure
> to httpd in the first place. Yes it means you gain some portability,
> but the downside is that you lose an awful lot of power that comes
> from the existing open source module ecosystem for httpd. That's not
> easily replaced, no matter what others may say.
>

Power indeed.

I wrote an application for case management that uses mod_perl's and
postgresql's specific features, via simple mod_perl handlers (LAMP to me
means Linux/Apache/Mod_Perl/Postgres).

The result is 15 milliseconds response times to generate an html page
with authentication and a hit to the database, on commodity hardware. My
application serves five to six users all day with a 1.6 Ghz processor
(200 dollar machine, 0 license) which peaks at 0.3% usage on busy
weekdays. That leaves me room for growth.

I don't suppose you can get the same numbers using frameworks?

--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique

Re: How do you use mod_perl for your web application?

On 15/06/11 10:01 PM, Fred Moyer wrote:
> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl.

We currently support an open source corporate CMS called Metapoint
http://www.metapointcms.com (derived from Metadot, derived from
the original Redhat CMS) which runs on mod_perl 1.3 and mod_perl 2.0.x
without change

It is fully dynamic. supporting MySQL, Postgres, SQLLite and Oracle.
It easily integrates with external systems including VOIP and and
source control applications. It is easily extendible so that any
code can be called through wrappers in perl modules.

We do nothing fancy with mod-perl, everything is done with
Apache::Registry. We use a fair number of Apache modules, including
mod_deflate as Fred mentioned earlier.

In order to leverage other programmers work we have spent a lot
of time looking at web frameworks and have a prototype running
under Catalyst. We will gradually port our code ( and clean up
a lot of crap) to Catalyst and I hope to be running on it
within a year.

Years ago we compiled apache, mod_perl and our other modules from
source but now we rely on the CentOS packages.

I really have no interest in perl webservers per se but I would like
to hear about other frameworks that may meet our needs.
Mojolicious appears to be a little underdeveloped for what we want
but I am willing to be corrected on this.

HTH
Dave

--
Dave Morgan
Operations Manager, BorealEscapes
http://www.borealescapes.ca
dave.morgan@borealescapes.ca
403 288 8759

Re: How do you use mod_perl for your web application?

> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl. Given the number
> of emerging Perl based webservers on CPAN (in addition to Nginx,
> lighty, etc), it seems like there are many more Perl web application
> and webservers out there now than there were five years ago.
[sNip]

I'm using mod_perl2 for custom internet site development. Where
many people might use static HTML pages, or other programming
languages such as JSP (and others), I have a .pl (Perl source code)
file in its place (e.g., "index.pl" instead of "index.html").

On one of my web sites, I documented the steps that I use to
configure mod_perl2 for this (working sample source code included):

How to install and configure ModPerl 2
http://www.modperl.pl/how-to/

I am hosting hundreds of web sites that I developed with mod_perl2,
and although most of them are small (and static pages could have
worked just fine too), there are a few that have PostgreSQL database
backends (membership management, PayPal integration, full transaction
history browsing, private forums, etc.).

I did use DBIx::Class for a while, but eventually moved back to
straight DBI (and I just finished converting the last site a few days
ago). I think DBIx::Class is a wonderful system, but the problem I
had with it is that new versions were behaving unexpectedly in ways
that would cause my web sites to stop functioning (unless I enabled
various "backward compabitility" options), and then re-generating
classes eventually resulted in the custom classes having to be
updated as well. So, I moved back to DBI which is doing the job very
well for me, and which I find is also more flexible despite being a
little bit less convenient. I suspect that I wouldn't be running
into these issues with a framework system designed to work with
DBIx::Class. A DBIx developer in IRC explained to me once that
DBIx::Class also goes to great lengths to shut off connection caching
from the Apache::DBI module -- after switching back to DBI, the
resulting performance gain has me wondering if this is correct.

At one point I started to create a telnet server for a BBS-type
system (just for fun), but had to put it on the back-burner due to
time-constraints (customizing one of Apache 2 HTTPd's connection
handlers made this possible). Originally I started out using
mod_perl on Novell's NetWare OS, but Novell stopped pre-compiling
mod_perl2 so I switched to NetBSD (which I've been using ever since).

I also started writing a Wiki system from scratch, and plan to
continue with that eventually.

I don't use proxying or virtualization for my web servers (it's all
running bare-metal), just raw mod_perl2. I'm extremely pleased with
the high performance and solid reliability that I get from mod_perl2
on NetBSD servers, and intend to keep using it (and promoting it) for
years to come.

Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com

Re: How do you use mod_perl for your web application?

On Fri, Jun 17, 2011 at 7:28 PM, Randolf Richardson wr=
ote:
> I suspect that I wouldn't be running
> into these issues with a framework system designed to work with
> DBIx::Class.

I don't think mod_perl should have more trouble cooperating with
DBIx::Class than other web environments. However, some of the people
who use DBIx::Class are vocal mod_perl haters, so they may not give
very good advice about how to set it up with mod_perl.

>=A0A DBIx developer in IRC explained to me once that
> DBIx::Class also goes to great lengths to shut off connection caching
> from the Apache::DBI module -- after switching back to DBI, the
> resulting performance gain has me wondering if this is correct.

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.

Sounds like you're having a good time with your mod_perl stuff! Good to he=
ar.

- Perrin

Re: How do you use mod_perl for your web application?

We use Mason 1.x inside a custom web framework (which I've recently =
gotten permission to release open-source), under mod_perl/Apache 2. =
Working on a transition to Plack and Mason 2, but we've already =
integrated the superior stack traces and debug console from Plack =
middleware.

On Jun 15, 2011, at 9:01 PM, Fred Moyer wrote:

> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl. Given the number
> of emerging Perl based webservers on CPAN (in addition to Nginx,
> lighty, etc), it seems like there are many more Perl web application
> and webservers out there now than there were five years ago.
>=20
> I'll start. I have a couple of Apache::Dispatch based applications I
> wrote. I also work on an Apache::ASP large codebase, and a couple of
> different Catalyst based systems. All are running on mod_perl 2.0.4
> in production (the ops haven't upgraded to 2.0.5 yet).
>=20
> If I were to migrate, I would probably try out something like
> Mojolicious on Plack on mod_perl2. Performance of mod_perl2 has never
> been an issue to date, but I have Perlbal doing connection handling as
> a reverse proxy.

Re: How do you use mod_perl for your web application?

> On Fri, Jun 17, 2011 at 7:28 PM, Randolf Richardson =
wrote:
> > I suspect that I wouldn't be running
> > into these issues with a framework system designed to work with
> > DBIx::Class.
>
> I don't think mod_perl should have more trouble cooperating with

Oh, please don't get me wrong -- I wasn't, for even a minute,
thinking that mod_perl was the culprit. When modules that add
functionality like Java's "try {} catch {}" paradigms work just fine
under mod_perl2, I have very little reason to doubt its capabilities.

> DBIx::Class than other web environments. However, some of the people
> who use DBIx::Class are vocal mod_perl haters, so they may not give
> very good advice about how to set it up with mod_perl.

I was hoping that this wasn't the case. It's really a shame when
someone hates a given technology. 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., but I've already committed to using
mod_perl2 for so many things, and for so many years, that I just
write it off as "enthusiasm that's gone a bit too far." I hope that
the fact that I'm out there mentioning mod_perl2 from time-to-time,
and without trying to push it on others, does help a little bit.

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. I think
that a product that works well and is based on quality code certainly
has the potential to see fewer updates, but this does start some
interesting debates about what a lot of unknown people are thinking.

> >=A0A DBIx developer in IRC explained to me once that
> > DBIx::Class also goes to great lengths to shut off connection caching
> > from the Apache::DBI module -- after switching back to DBI, the
> > resulting performance gain has me wondering if this is correct.
>
> 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).

> Sounds like you're having a good time with your mod_perl stuff! Good to=
hear.

It's wonderful. I just love how fast it is, and how well it
integrates so closely with Apache HTTPd. I've got a few friends
getting interested in it lately (and one of them has been doing a lot
of PHP development, but wants to find a way to go back to Perl, so I
helped him get it working).

Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com

Re: How do you use mod_perl for your web application?

We are using Mason 1.x, a (little) modified version of MasonX::WebApp =
together with Apache2 and mod_perl2 running behind a lightweight =
Apache as frontend-server. We use mod_perl for Mason and =
Apache2::UploadProgress , no other mod_perl handlers. Session management =
is done with MasonX::WebApp and Apache::Session::Wrapper.=20

I've been playing around with Mason2, Plack, Catalyst and Dancer, where =
I liked the easier data passing to my templates than with MasonX::WebApp =
in Catalyst, which leads to a stricter separation from HTML and Perl =
code. Yet I haven't made any tests with file uploading in combination =
with a progress-meter on the client side and some other aspects that are =
important for us, so there is no decision yet, if we will using Apache =
and mod_perl for this or switch to a PSGI Server or even nginx. The =
current standing is to switch to Catalyst with Mason2, but this is a =
long way to go.

There is one point that I would like to see in mod_perl that would help =
me a lot:

Currently, I can use on Perl instance in all virtual hosts or add a =
separate instance with +Parent for a virtual host. Yet , if I have some =
virtual hosts running with version A , some with Version B, some with =
Version C I have to add +Parent for each vhost and I,m running out of =
memory. So , I would like to make instance pools one for each version , =
and tell each vhost just, which pool to use.
So, memory usage is a con for mod_perl, or in other words , if I would =
found a PSGI based solution which allows something like this this would =
be an argument for me to switch!



Rolf Schaufelberger

Re: How do you use mod_perl for your web application?

--000e0cd56af80308d604a6375b98
Content-Type: text/plain; charset=ISO-8859-1

We use mp2 + httpd in prefork mode to translate between JSON/SOAP to
proprietary CORBA (via opalORB - the 100% painless CORBA interface) on
dedicated servers .

We've run 100's of requests a second through a single server. So long as
httpd is configured sensibly the performance is excellent. A word too on
stability. One installation has been chugging away for about 4 years now
without a single defect report.

I also use it for internal testing - using virtual hosts to serve a
proprietary in-house socket protocol, which is then reconstituted inside
perl. The advantage of this is that I can use Apache::Test to drive the
tests.

So far the need for frameworks of any sort has not arisen. The ones I have
played with, Mason,Catalyst,Gantry, Dancer are all very capable. Probably it
is due to the limited use I've put them to but I tend to find that
Text::Perlate (or even just some quick and dirty regex-based text
mutations), and maybe a bit of javascript gets me there quicker than the
frameworks. That said - I have an uncomfortable suspicion that sophisticated
technology leads to sophisticated solutions, whether the problems at hand
deserve such sophistication or not.

Just to reinforce Randolf's enthusiasm - mod_perl is fantastic. Combined
with httpd's remarkable flexibility and stability I can't see why we don't
brainwash our children into using it as soon as they can hit a keyboard.

--000e0cd56af80308d604a6375b98
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We use mp2 + httpd in prefork mode to translate between JSON/SOAP to propri=
etary CORBA (via opalORB - the 100% painless CORBA interface) on dedicated =
servers .

We've run 100's of requests a second through a si=
ngle server. So long as httpd is configured sensibly the performance is exc=
ellent. A word too on stability. One installation has been chugging away fo=
r about 4 years now without a single defect report.


I also use it for internal testing - using virtual hosts to serve a pro=
prietary in-house socket protocol, which is then reconstituted inside perl.=
The advantage of this is that I can use Apache::Test to drive the tests. r>

So far the need for frameworks of any sort has not arisen. The ones I h=
ave played with, Mason,Catalyst,Gantry, Dancer are all very capable. Probab=
ly it is due to the limited use I've put them to but I tend to find tha=
t Text::Perlate (or even just some quick and dirty regex-based text mutatio=
ns), and maybe a bit of javascript gets me there quicker than the framework=
s. That said - I have an uncomfortable suspicion that sophisticated technol=
ogy leads to sophisticated solutions, whether the problems at hand deserve =
such sophistication or not.


Just to reinforce Randolf's enthusiasm - mod_perl is fantastic. Com=
bined with httpd's remarkable flexibility and stability I can't see=
why we don't brainwash our children into using it as soon as they can =
hit a keyboard.





--000e0cd56af80308d604a6375b98--

Re: How do you use mod_perl for your web application?

On Mon, Jun 20, 2011 at 11:00 PM, Randolf Richardson 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

Re: How do you use mod_perl for your web application?

On Tue, Jun 21, 2011 at 2:25 AM, Rolf Schaufelberger wrote:
> We are using Mason 1.x, =A0a (little) modified version of MasonX::WebApp

Us too! Glad to know someone else is using it.

> Currently, =A0I can use on Perl instance in all virtual hosts =A0or add =
=A0a separate instance with +Parent for a virtual host. Yet , if I have =A0=
some virtual hosts running with version A , some with Version B, =A0some wi=
th Version C =A0I have to add +Parent for each =A0vhost and I,m running out=
of memory. So , I would like to make instance pools one for each version ,=
and tell each vhost =A0just, which pool to use.

My approach to this problem would be to run separate httpd servers for
each version of the code you need to support and use a proxy in front
to do the dispatching.

- Perrin

Re: How do you use mod_perl for your web application?

On Thu, 16 Jun 2011 06:01:03 +0200, Fred Moyer
wrote:

> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl.

A bit late to the party.

In Opera we have lots of systems running modperl 2, ranging
from 1 server to moderately large and critical apps.
For the most part we use an in-house framework started
many years ago.

Recently we have seen two friendly factions struggling
for power :), one moving towards Catalyst/DBIx/TT2 and
another testing Plack/PSGI.

Latest new project I deployed in production is a psgi
single sign on server that uses Plack::Handler::Apache2.

> ... emerging Perl based webservers on CPAN

Yes, very interesting. I'm planning to compare
raw modperl 2, Plack::Handler::Apache2 and starman for
the same application and extract some performance data.

> Performance of mod_perl2 has never been an issue to date

Yeah, also wrt stability. For medium and large scale systems
we usually deploy frontends as reverse proxies using
any of apache, nginx, varnish, perlbal or pound.

--
Cosimo

Re: How do you use mod_perl for your web application?

On Jun 21, 2011, at 9:33 AM, Cosimo Streppone wrote:

> Recently we have seen two friendly factions struggling
> for power :), one moving towards Catalyst/DBIx/TT2 and
> another testing Plack/PSGI.

To be clear, these two factions are orthogonal. FWIW, Catalyst is being =
updated to run on Plack.

Best,

David

Re: How do you use mod_perl for your web application?

Am 21.06.2011 um 18:12 schrieb Perrin Harkins:

> On Tue, Jun 21, 2011 at 2:25 AM, Rolf Schaufelberger =
wrote:
>> We are using Mason 1.x, a (little) modified version of =
MasonX::WebApp
>=20
> Us too! Glad to know someone else is using it.

Same to me, didn't hear from somebody else using it. When I started =
with it there weren't much alternatives, David Wheelers =
Interp::WithCallbacks or Maypole and that was it.=20

>=20
>> Currently, I can use on Perl instance in all virtual hosts or add =
a separate instance with +Parent for a virtual host. Yet , if I have =
some virtual hosts running with version A , some with Version B, some =
with Version C I have to add +Parent for each vhost and I,m running =
out of memory. So , I would like to make instance pools one for each =
version , and tell each vhost just, which pool to use.
>=20
> My approach to this problem would be to run separate httpd servers for
> each version of the code you need to support and use a proxy in front
> to do the dispatching.
>=20
> - Perrin

yes, I've tried this too, but this leads to a big memory footprint too. =
If you have 10 sites and make separate (preforking) instance for each =
vhost, with StartServers =3D 2 and set the other parameters =
(Min/MaxSpareServers etc) to low values, you quickly get 20 oder 30 fat =
apache processes. Ok, you can get this running with enough memory, but =
the idea of instance pools seems to be a better and more elegant =
solution for this. I've discussed this once with Torsten Förtsch who =
is a mod_perl expert nearby, his opinion was, that it wouldn't be very =
much code that has to be added for this.

Rolf Schaufelberger

Re: How do you use mod_perl for your web application?

On Tue, Jun 21, 2011 at 5:03 PM, Rolf Schaufelberger wrote:
>> My approach to this problem would be to run separate httpd servers for
>> each version of the code you need to support and use a proxy in front
>> to do the dispatching.
>
> yes, I've tried this too, but this leads to a big memory footprint too. I=
f you have 10 sites and make separate (preforking) instance for each vhost,=
with StartServers =3D 2 and set the other parameters (Min/MaxSpareServers =
etc) to low values, you quickly get 20 oder 30 fat apache processes. Ok, yo=
u can get this running with enough memory, =A0but the idea of =A0instance p=
ools seems to be a better and more elegant solution for this.

I don't understand what would be different. My suggestion was to run
one httpd server for each version of the code that you need, possibly
with virtual hosts on each if there are multiple hosts that use the
same version of the code. If you had an "instance pool", wouldn't it
also be multiple processes (or threads if you prefer) per version of
code? I don't see how you could avoid that. Were you thinking you'd
reset the perl interpreters completely between requests so that one
could be shared between multiple versions of code?

> I've discussed this once with Torsten Förtsch who is a mod_perl expert =
nearby, his opinion was, that it wouldn't be =A0very much code that has to =
be added for this.

Torsten is a major contributor and I'm sure that whatever he had in
mind would be cool.

- Perrin

Re: How do you use mod_perl for your web application?

--001636831732fd88a004a66ddea5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

One should really try mod_fcgid + perl application. that is lighter, faster=
,
and more stable.
mod_fcgid provides also authenticate/authorize/access controls, besides
dynamical content.
These are probably all you want to get from mod_perl.


On Tue, Jun 21, 2011 at 2:13 PM, Perrin Harkins wrote:

> On Tue, Jun 21, 2011 at 5:03 PM, Rolf Schaufelberger wrote:
> >> My approach to this problem would be to run separate httpd servers for
> >> each version of the code you need to support and use a proxy in front
> >> to do the dispatching.
> >
> > yes, I've tried this too, but this leads to a big memory footprint too.
> If you have 10 sites and make separate (preforking) instance for each vho=
st,
> with StartServers =3D 2 and set the other parameters (Min/MaxSpareServers=
etc)
> to low values, you quickly get 20 oder 30 fat apache processes. Ok, you c=
an
> get this running with enough memory, but the idea of instance pools see=
ms
> to be a better and more elegant solution for this.
>
> I don't understand what would be different. My suggestion was to run
> one httpd server for each version of the code that you need, possibly
> with virtual hosts on each if there are multiple hosts that use the
> same version of the code. If you had an "instance pool", wouldn't it
> also be multiple processes (or threads if you prefer) per version of
> code? I don't see how you could avoid that. Were you thinking you'd
> reset the perl interpreters completely between requests so that one
> could be shared between multiple versions of code?
>
> > I've discussed this once with Torsten Förtsch who is a mod_perl exper=
t
> nearby, his opinion was, that it wouldn't be very much code that has to =
be
> added for this.
>
> Torsten is a major contributor and I'm sure that whatever he had in
> mind would be cool.
>
> - Perrin
>

--001636831732fd88a004a66ddea5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

One should really try mod_fcgid + perl application. that is lighter, faster=
, and more stable.
mod_fcgid provides also authenticate/authorize/access=
controls, besides dynamical content.
These are probably all you want to=
get from mod_perl.

Re: How do you use mod_perl for your web application?

On Fri, Jun 24, 2011 at 12:45 PM, Phil Van wrote:
> One should really try mod_fcgid + perl application. that is lighter, faster,
> and more stable.
> mod_fcgid provides also authenticate/authorize/access controls, besides
> dynamical content.
> These are probably all you want to get from mod_perl.
>

Do you mean this module:
http://httpd.apache.org/mod_fcgid/

Yes the author of mod_fcgid is one of my friends.
He wrote the module orignally for NetEase webmail systems, and it
behave well there.
The PV each day for netease freemail systems is more than 100 million I believe.

And for mod_perl, I have been running a mp2 handler in our production
application for more than 3 years, never had problems.

xiaolan

Re: How do you use mod_perl for your web application?

On Fri, Jun 24, 2011 at 12:45 AM, Phil Van wrote:
> One should really try mod_fcgid + perl application. that is lighter, faster,
> and more stable.

FastCGI works fine, but these claims are not true. I benchmarked
several FastCGI environments and none of them were significantly
faster than mod_perl. They are also not lighter. The only thing
"heavy" in mod_perl is Perl, and that will be there in FastCGI, PSGI,
etc.

> mod_fcgid provides also authenticate/authorize/access controls, besides
> dynamical content.

True, but my experience is that the documentation for these is pretty
weak compared to the mod_perl equivalent. They don't seem to be used
by many people. The ones for mod_perl are widely used and have many
modules on CPAN for common needs.

However, the trend is to move these functions away from server APIs
and put them in the application framework, so it may be a moot point.

- Perrin

Re: How do you use mod_perl for your web application?

--00163630f39b5bff6004a679cf39
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jun 24, 2011 at 8:10 AM, Perrin Harkins wrote:

> On Fri, Jun 24, 2011 at 12:45 AM, Phil Van wrote:
> > One should really try mod_fcgid + perl application. that is lighter,
> faster,
> > and more stable.
>
> FastCGI works fine, but these claims are not true. I benchmarked
> several FastCGI environments and none of them were significantly
> faster than mod_perl. They are also not lighter. The only thing
> "heavy" in mod_perl is Perl, and that will be there in FastCGI, PSGI,
> etc.
>

Interesting.... those are mod_fcgid + CGI, compared to plain Apache +
mod_perl + libapeq ?

I think all those application servers end up at roughly the same speed. In
my cases, mod_fcgid has fewer memory footprint, which is typically around
15-20M per application loaded with common modules like DBI, SHA1 and JSON.
Eventually, one may serve more fcgid applications on the same machine.


>
> > mod_fcgid provides also authenticate/authorize/access controls, besides
> > dynamical content.
>
> True, but my experience is that the documentation for these is pretty
> weak compared to the mod_perl equivalent. They don't seem to be used
> by many people. The ones for mod_perl are widely used and have many
> modules on CPAN for common needs.
>
>
This is true. The earlier mod_fastcgi is commercial licensed; and the
support to AAA is almost broken. But the new fcgid, originally designed by
xiaolan's friend (as in the previous post) is very active in development. As
far as I know, it would be one of the standard modules in the coming httpd
2.4.

I am also trying to promote the new mod_fcgid here :-)

Here is a typical scenario to run AAA in Fast::CGI

1) enable FCGI aaa program on the directory via httpd.conf or .htaccess
2) run aaa_program($r) if ($ENV->{FCGI_ROLE} && ($ENV->{FCGI_ROLE} eq
'AUTHORIZER'));
3) return 200 OK if it passes, or 401 if fails

However, the trend is to move these functions away from server APIs
> and put them in the application framework, so it may be a moot point.
>
>
This is a bad idea --- how about to serve a static mp3 in member area? We
lose the advantages to serve the file as NOT MODIFIED, or system's efficient
sendfile call.


> - Perrin
>

--00163630f39b5bff6004a679cf39
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Jun 24, 2011 at 8:10 AM, Perrin Harkins <<=
a href=3D"mailto:perrin@elem.com">perrin@elem.com> wrote:
=

Re: How do you use mod_perl for your web application?

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.

> I think all those application servers end up at roughly the same speed.

Yes, that's what I've seen.

> In
> my cases, mod_fcgid has fewer memory footprint, which is typically around
> 15-20M per application loaded with common modules like DBI, SHA1 and JSON.
> Eventually, one may serve more fcgid applications on the same machine.

Are you comparing that to mod_perl with a proxy server in front of it?
That is the equivalent architecture. If you remove the proxy,
mod_perl becomes faster but the scalability suffers. I wouldn't
recommend anyone run mod_perl without a frontend proxy of some kind.

> This is true. The earlier mod_fastcgi is commercial licensed; and the
> support to AAA is almost broken. But the new fcgid, originally designed by
> xiaolan's friend (as in the previous post) is very active in development. As
> far as I know, it would be one of the standard modules in the coming httpd
> 2.4.

Better FastCGI support for Apache would be great.

> I am also trying to promote the new mod_fcgid here :-)

I think the main competition among FastCGI users is pure-perl daemons
as FastCGI backends. I had good success in my tests with one of
those.

> This is a bad idea --- how about to serve a static mp3 in member area? We
> lose the advantages to serve the file as NOT MODIFIED, or system's efficient
> sendfile call.

You actually can access efficient file serving through the mod_perl
API, but I agree, auth in the app framework is often a bad solution.
My favorite solution so far has been to use things like mod_auth_tkt
which let you write a complex auth system in your favorite language
and then check credentials from an efficient C module that can guard a
static file directory.

- Perrin

Re: How do you use mod_perl for your web application?

--e0cb4e5934beea715804a67b0801
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jun 24, 2011 at 12:17 PM, Perrin Harkins wrote:

>
>
> Are you comparing that to mod_perl with a proxy server in front of it?
> That is the equivalent architecture. If you remove the proxy,
> mod_perl becomes faster but the scalability suffers. I wouldn't
> recommend anyone run mod_perl without a frontend proxy of some kind.
>
>
This is exactly what I saw.


Better FastCGI support for Apache would be great.
>


I have some FastCGI programs, let me see if I could pack them and upload to
CPAN.



>
> You actually can access efficient file serving through the mod_perl
> API, but I agree, auth in the app framework is often a bad solution.
> My favorite solution so far has been to use things like mod_auth_tkt
> which let you write a complex auth system in your favorite language
> and then check credentials from an efficient C module that can guard a
> static file directory.
>
> - Perrin
>


Totally agree. Moving system-wide operations to C modules as far as
possible.

--e0cb4e5934beea715804a67b0801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 24, 2011 at 12:17 PM, Perrin Harkins < ref=3D"mailto:perrin@elem.com">perrin@elem.com> wrote:
v class=3D"gmail_quote">

0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Are you comparing that to mod_perl with a proxy server in front of it=
?

=A0That is the equivalent architecture. =A0If you remove the proxy,

mod_perl becomes faster but the scalability suffers. =A0I wouldn't

recommend anyone run mod_perl without a frontend proxy of some kind.

border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Better Fast=
CGI support for Apache would be great.

0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
">You actually can access efficient file serving through the mod_perl

API, but I agree, auth in the app framework is often a bad solution.

My favorite solution so far has been to use things like mod_auth_tkt

which let you write a complex auth system in your favorite language

and then check credentials from an efficient C module that can guard a

static file directory.



- Perrin

Re: How do you use mod_perl for your web application?

> 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.

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.).

Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com

Re: How do you use mod_perl for your web application?

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
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

Re: How do you use mod_perl for your web application?

On Sun, Jun 26, 2011 at 5:11 PM, Randolf Richardson wr=
ote:
> =A0 =A0 =A0 =A0I believe Catalyst depends on DBIx::Class

As Octavian said, there isn't really a connection between the two.
Catalyst people often use DBIx::Class, but there's no tie at a code
level.

> =A0 =A0 =A0 =A0To be fair, I think it would be important to run benchmark=
s 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.).

For this benchmark, I was simply trying to determine whether or not
the process management and buffering of the different web runtimes
made a significant performance difference. I'm pleased to report that
the differences are small, so you can use the one that you like best
for other reasons.

- Perrin

Re: How do you use mod_perl for your web application?

On Sun, Jun 26, 2011 at 10:55 PM, Octavian Rasnita wrote:
> From: "Randolf Richardson"
>> 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.

Do you have any evidence for this claim? I've been using DBIx::Class
with Apache::DBI for several years and have never seen anything to
this effect.

Re: How do you use mod_perl for your web application?

On 6/27/11 8:37 AM, "Fred Moyer" wrote:

>>DBIx::Class just does its own persistent connection and this is why it
>>doesn't need Apache::DBI.
>
>Do you have any evidence for this claim? I've been using DBIx::Class
>with Apache::DBI for several years and have never seen anything to
>this effect.
>

While this may not be the last word on this subject of DBIx::Class Db conn
caching,
a cursory glance at the documentation shows:
(http://search.cpan.org/~frew/DBIx-Class-0.08192/lib/DBIx/Cl ass/Manual/Intr
o.pod#Connecting)

Note that DBIx::Class::Schema does not cache connections for
you. If you use multiple connections, you need to do this
manually.

Re: How do you use mod_perl for your web application?

On 6/27/11 11:44 AM, "McCarrell, Jeff" wrote:

>While this may not be the last word on this subject of DBIx::Class Db conn
>caching,
>a cursory glance at the documentation shows:
>(http://search.cpan.org/~frew/DBIx-Class-0.08192/lib/DBIx/C lass/Manual/Int
>r
>o.pod#Connecting)
>
> Note that DBIx::Class::Schema does not cache connections for
> you. If you use multiple connections, you need to do this
> manually.

Poking a little bit further,
(http://search.cpan.org/~frew/DBIx-Class-0.08192/lib/DBIx/Cl ass/Storage/DBI
..pm#connect_info)
it looks like DBIx::Class caches statement handles via DBI
(see disable_sth_caching which explicitly disables this caching)
and that the design is oriented toward re-connecting to the DB
transparently,
as long as AutoCommit is turned on; which Apache::DBI also does.
I believe that DBIx::Class is not as well suited for interleaving
different SQL statements on the same connection as Apache::DBI because of
its
deeper assumptions about error handling and the state it assumes
across SQL statements.

So it appears that DBIx::Class does do its own connection handling,
but aimed at a different design center than Apache::DBI.

HTH,

-- jeff

Re: How do you use mod_perl for your web application?

Here is a comment that might be helpful, because it also explains why =
DBIx::Class can work with Apache::DBI (and why it is not needed):

http://lists.scsys.co.uk/pipermail/dbix-class/2006-April/001 153.html

""
DBIx::Class already manages its connections for you, and therefore it
cannot benefit from Apache::DBI under any scenario. It makes one
connection per-process, and keeps that connection persistent,
reconnecting only if the connection appears to have died, or if you
fork/thread over to another process/thread-id. The only Apache::DBI
issue in DBIx::Class is that Apache::DBI will actually thwart
DBIx::Class's connection management code, and cause it to use the same
(and invalid) connection in a new process, in cases such as (as
mentioned above) if you make a DBI connection before forking in a
prefork mod_perl server.
=20
To work around this, DBIx::Class has specific code in it to work
around Apache::DBI, nullifying the effects of Apache::DBI on
DBIx::Class. Essentially, loading Apache::DBI should change nothing
and be rather pointless under DBIx::Class.

The only reason we support it (support working around it) is because
someone might want Apache::DBI loaded up under the same mod_perl as a
DBIx::Class application to support a different legacy application
which does not use DBIx::Class, in which case they share a perl
interpreter and will both have the same set of modules loaded.
""

Octavian

----- Original Message -----=20
From: "Fred Moyer"
To: "Octavian Rasnita"
Cc: ; "mod_perl list"
Sent: Monday, June 27, 2011 6:37 PM
Subject: Re: How do you use mod_perl for your web application?


> On Sun, Jun 26, 2011 at 10:55 PM, Octavian Rasnita =
wrote:
>> From: "Randolf Richardson"
>>> 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.
>=20
> Do you have any evidence for this claim? I've been using DBIx::Class
> with Apache::DBI for several years and have never seen anything to
> this effect.

Re: How do you use mod_perl for your web application?

On Jun 27, 2011, at 12:53 PM, Octavian Rasnita wrote:

> DBIx::Class already manages its connections for you, and therefore it
> cannot benefit from Apache::DBI under any scenario. It makes one
> connection per-process, and keeps that connection persistent,
> reconnecting only if the connection appears to have died, or if you
> fork/thread over to another process/thread-id. The only Apache::DBI
> issue in DBIx::Class is that Apache::DBI will actually thwart
> DBIx::Class's connection management code, and cause it to use the same
> (and invalid) connection in a new process, in cases such as (as
> mentioned above) if you make a DBI connection before forking in a
> prefork mod_perl server.
>
> To work around this, DBIx::Class has specific code in it to work
> around Apache::DBI, nullifying the effects of Apache::DBI on
> DBIx::Class. Essentially, loading Apache::DBI should change nothing
> and be rather pointless under DBIx::Class.
>
> The only reason we support it (support working around it) is because
> someone might want Apache::DBI loaded up under the same mod_perl as a
> DBIx::Class application to support a different legacy application
> which does not use DBIx::Class, in which case they share a perl
> interpreter and will both have the same set of modules loaded.

The same statements apply to DBIx::Connector, FWIW.

Best,

David

Re: How do you use mod_perl for your web application?

On 06/15/2011 09:01 PM, Fred Moyer wrote:
> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl. Given the number
> of emerging Perl based webservers on CPAN (in addition to Nginx,
> lighty, etc), it seems like there are many more Perl web application
> and webservers out there now than there were five years ago.

There are probably several thousand installations of our application
running under mod_perl. (We guess that there are roughly 10,000
installations of Bugzilla, some large number of which are running under
mod_perl.)

We don't really have a web framework (unless you count CGI.pm, which I
don't), we just have a bunch of raw CGI files. The application dates
originally from 1998 and is developed on an entirely volunteer basis, so
we have a legacy from that era. The exact same code also runs under
mod_cgi for users who have trouble installing mod_perl (or want to run
multiple installations on one machine with different code).

We require only mod_perl 1.999022, but nowadays also require
Apache2::SizeLimit 0.93, which may raise the effective minimum mod_perl
requirement.

The performance and configuration ease of mod_perl have been generally
excellent for us--our only serious problems have been with people having
their servers' memory exhausted (which is why I frequently talk/ask
about SizeLimit on this list) and the occasional problem with a CPAN
module that doesn't work right in mod_perl.

-Max
--
Max Kanat-Alexander
Chief Architect, Community Lead, and Release Manager
Bugzilla Project
http://www.bugzilla.org/

Re: How do you use mod_perl for your web application?

On 2 Jul 2011, at 08:38, Max Kanat-Alexander wrote:

> (which is why I frequently talk/ask
> about SizeLimit on this list)

And I will frequently say that this is the Wrong Answer. MaxClients
and a proxy on the front is more often the right answer. A fat
Apache is an application server, treat it as such.

Re: How do you use mod_perl for your web application?

On 6/15/2011 9:01 PM, Fred Moyer wrote:
> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl. Given the number
> of emerging Perl based webservers on CPAN (in addition to Nginx,
> lighty, etc), it seems like there are many more Perl web application
> and webservers out there now than there were five years ago.

One-page app. using Ajax/JSON.

Server side is mod_perl 2.x, Apache (configured variously for proxy,
static content and mod_perl) and MySQL. Code is OO and uses persistent
objects. No frameworks or much use of CPAN modules other than DBI.

Cient interface is assembled entirely on client, using JavaScript and
DOM. This frees up server from having to do any interface generation.

Regardless of request type (POST/GET etc), the server response is in the
form of JavaScript object(s) (really just a plain text string), which is
'eval'ed by JavaScript on the client.