mod_perl (was Re: [boulder.pm] meeting?)

Rob Nagler nagler at bivio.biz
Tue Sep 3 22:12:31 CDT 2002


[Consilidated threads and concatenated messages.  Don't want to scare
anybody off boulder-pm, because of the volume. --Rob :-]

Chip Atkinson writes:
> I remember looking at mod_perl, but don't remember why not.  I think it
> was one of those things where I was totally fed up with some things and
> didn't want to deal with it.

:)  I actually don't deal much with mod_perl any more, because our
infrastructure hides it completely.

> I wish I had been able to get that far.  I was having trouble building the
> module at all.  My biggest concern/worry is whether or not I'm approaching
> the problem in the best way.  I decided to try the PHP approach with a
> reentrant script that loops through and prints out different text based on
> the type of page I was and wanted to display.

This works fine.  If the problem is simple, PHP is great.  I do have
some opinions about how to build Web applications.  For the
curious:

http://www.bivio.biz/hm/why-bOP

Myke Komarnitsky writes:
> Getting back to the meeting talk, I would love (and definitely come to) a 
> presentation on mod_perl.... specifically:

I've got quite a bit of experience using mod_perl.  It's really easy,
BUT it doesn't give you enough imiho.  You have to build or "buy"
something on top of it.

> 1) when:  when does a site really NEED to be done in mod_perl?

Always. :-)  Seriously, I have build applications using Java, CGI (on
Tandem, NT, and Unix) and Perl.   I wouldn't do it in anything else
but Perl (well maybe Lisp if there was a CLAN. ;-).

> I've heard anecdotal speed increases, but more the brass tacks.

For speed, we find the database is the limiting factor.  We build all
our sites now in Perl.  All are dynamically rendered.  This page:

http://www.bivio.com/club_index/accounting/investments

is produced from the base transactions (buys, splits, spinoffs, sells)
in an Oracle database (450mhz box with RAID and 10K disks) using
750mhz middle tier (mod_perl) and front ends (mod_proxy).   At least
50% of the time is spent waiting for Oracle.

> 2) how: code snippets, setting up persistent db connections, perhaps sample 
> 'old' perl code and what it takes to migrate to mod_perl

You can transfer CGI to mod_perl very easily.  The Apache::Registry
and a few other modules make it transparent.  While this is ok, it's
not why I would go to mod_perl.  The real advantage is that it allows
you to build an application framework like bOP or bricolage or AxKit
or yada yada.

You can view the source of our Pet Shop application online:

http://petshop.bivio.biz

You can also download it: http://www.bivio.biz/hm/download-bOP

> I've tried to dip my foot in this pool a number of times and have been 
> thrwarted.  Plus, I have a couple of projects that might be extremely 
> relevant to this soon.

It is an investment, but I believe thinking about web sites as
"applications" makes a world of difference.  It's frustrating going
back to templating systems like Java/JSP (we're doing one now and it
is twice or three times as slow to build the application than with
bOP).

Walter Pienciak writes:
> You speak of bOP when you say 'our infrastructure'?

Yassuh.

> > If you are installing a new release, you just install it and
> > restart the server.  No worries about "woops, file disappeared
> > in new release, but still serving old files".
> 
> I'm not following.  It seems clear you have a good example in mind,
> but whatever it is, I've never run across the problem, I think.

You have /cgi-bin/mainpage which refers to /cgi-bin/delete-all and
/cgi-bin/delete.  You decide to coalesce the two "delete"
implementations, so it is now /cgi-bin/delete?all.  Great, but at the
same time you remove /cgi-bin/delete-all from your source repository,
because it is no longer needed.  Unfortunately, when you install your
new release, somebody still has the old rendering of /cgi-bin/mainpage
and they click on the "delete all" link which goes to
/cgi-bin/delete-all which is no longer there.

Yes, you can work around us, but in bOP and other frameworks which
separate the controller from the business logic, you setup aliases
(redirects) to deal with this problem.  In CGI, where there is no
clear control flow, it's difficult to have the overview esp. when
there are 50 entry points (delete, delete-all, upload, rename, ...)

> I guess I'm just feeling argumentative (in a good-natured way)
> today,

This isn't like you, Walter.  Perhaps we need to play some disc golf
to get out your aggressions.

> but doesn't mod_perl bring its own set of headaches to the table
> -- memory leaks for example -- that for simpler solutions point back
> to CGI as preferable?

We've had some slow leaks, but with the right infrastructure, not a
problem.  Everynight we restart the slaves when we chomp the logs for
the new day.

> There's no doubt that for high-performance
> systems mod_perl is clearly preferable -- in-memory and ready to go,
> persistent database connections, etc. -- but my preference for low-end
> low-usage programs is still CGI.  (I prefer a paper calendar to a
> PDA, too, so . . .)

Right.  The PDA is a good example.  I've been using one for 12 years.
I just got a Palm.  My old keyboard-based solution was just fine, but
now that I have the Palm, I'm much happier.  Old hiking boots are
great until you try the latest models (just did this, too).  It takes
a while to get used to anything before you see its inherent advantages
(and weaknesses).

> FWIW (for all those following along), all my servers are mod_perl enabled
> and I'm a huge fan of mod_perl handlers -- they are really easy to
> write and work with.  And you can do things using the API that you just
> can't do in CGI.  I just prefer CGI for the simple stuff.  Disk I/O and
> CPUs nowadays make the startup cost of infrequently requested apps
> insignificant to the user experience when compared with network
> latency (in my opinion, and the database-backend issue something separate
> entirely).

We run "reqtrack" (reqng) which is a 5000 CGI application.  It's only
used for support requests (~10/day, max 50).  It works fine and we
have customized it to our needs.  No plans to change.

> Ah, gotta go.  My wife just got home, and it's time to go out to
> dinner (20th anniversary).  Woohoo!

Congrats!  I hope you bought her a string of Perls (hardy har har).

Rob





More information about the Boulder-pm mailing list