mod_perl warnings

[Seth Brundle]

I have been a perl cgi developer for about 8 years.
I have been wanting to develop a nice mod_perl system for a long time,
and recently did.

However, there are some significant drawbacks to mod_perl I have come
across in production that I wish were explained to people a lot more
prominantly as drawbacks to mod_perl.

1. With CGI, production changes are simple: copy the cgi to a
different filename, make and test changes, and copy it back -
something broken? revert to earlier copy in less then 1 second. With
mod_perl, it is much more involved, including renaming not only files
but module package names within the files (twice) and httpd.conf
entries, plus server hups. For this reason alone I am converting most
of my code back to CGI.

With CGI, I never hesitate to jump in and make the most trivial of
corrections to production code. With mod_perl, I usually let them
languish until the list is big enough to warrant the procedure.

2. If you have mod_perl which serves downloads, the downloads will be
disconnected during a webserver restart (like for log rotation), even
if it is graceful.

3. If you use persistant DBI, which is a primary reason to want to use
mod_perl, it frequently dumps tons of ignorable but extremely annoying
'attempt to free unreferenced scalar' messages in your weblogs which
are very difficult to weed out.

If anyone knows any workarounds to these problems, please let me know
- but when I have read other people post about them, you can hear
crickets chirp in response.

[Chad Hanna]

Hi,

In message <53e2ec95.0306260825.79680d79@posting.google.com >, Seth
Brundle <brundlefly76@hotmail.com> writes

>I have been a perl cgi developer for about 8 years.
>I have been wanting to develop a nice mod_perl system for a long time,
>and recently did.

Sounds like me!

>
>However, there are some significant drawbacks to mod_perl I have come
>across in production that I wish were explained to people a lot more
>prominantly as drawbacks to mod_perl.
>
>1. With CGI, production changes are simple: copy the cgi to a
>different filename, make and test changes, and copy it back -
>something broken? revert to earlier copy in less then 1 second. With
>mod_perl, it is much more involved, including renaming not only files
>but module package names within the files (twice) and httpd.conf
>entries, plus server hups. For this reason alone I am converting most
>of my code back to CGI.

I do not find this - but I do use mod_perl handlers rather than registry
or CGI like scripts. This means all my code is compiled at server
startup.

I prepare a new release, untar it into a new directory. Then when I
change over, I switch a symbolic link from the old directory to the new
directory and restart the server. I guess a similar approach would work
for Registry scripts - though the restart might no longer be needed.

>
>With CGI, I never hesitate to jump in and make the most trivial of
>corrections to production code. With mod_perl, I usually let them
>languish until the list is big enough to warrant the procedure.

My change control system means nothing is trivial, but other than the
small interruption during the restart (which I would need to schedule)
there is nothing to prevent me doing it.

>
>2. If you have mod_perl which serves downloads, the downloads will be
>disconnected during a webserver restart (like for log rotation), even
>if it is graceful.

Not sure I can answer this, but if this is critical I'd be tempted to
put these onto another web server instance - so that I wouldn't need to
restart it very often.

>
>3. If you use persistant DBI, which is a primary reason to want to use
>mod_perl, it frequently dumps tons of ignorable but extremely annoying
>'attempt to free unreferenced scalar' messages in your weblogs which
>are very difficult to weed out.

I get some but not tons - perhaps because all the database connections
that are requested are very similar.

>
>If anyone knows any workarounds to these problems, please let me know
>- but when I have read other people post about them, you can hear
>crickets chirp in response.

Well that's my story - please feel free to poke holes in it.
--
Chad Hanna
Chairman Berkshire Family History Society [url]www.berksfhs.org.uk[/url]
Quality Family History Data [url]www.familyhistoryonline.net[/url]

[Benjamin Goldberg]

Seth Brundle wrote:

>
> I have been a perl cgi developer for about 8 years.
> I have been wanting to develop a nice mod_perl system for a long time,
> and recently did.
>
> However, there are some significant drawbacks to mod_perl I have come
> across in production that I wish were explained to people a lot more
> prominantly as drawbacks to mod_perl.
>
> 1. With CGI, production changes are simple: copy the cgi to a
> different filename, make and test changes, and copy it back -
> something broken? revert to earlier copy in less then 1 second. With
> mod_perl, it is much more involved, including renaming not only files
> but module package names within the files (twice) and httpd.conf
> entries, plus server hups. For this reason alone I am converting most
> of my code back to CGI.

This shouldn't be necessary -- it should be possible to tell the server
to restart, or even to just reload those files which have changed,
without having to do all that renaming.

> With CGI, I never hesitate to jump in and make the most trivial of
> corrections to production code. With mod_perl, I usually let them
> languish until the list is big enough to warrant the procedure.
>
> 2. If you have mod_perl which serves downloads, the downloads will be
> disconnected during a webserver restart (like for log rotation), even
> if it is graceful.

Have you considered using mod_cgi for downloads, and mod_perl for
everything else? Remember, the biggest overhead of mod_cgi compared to
other apache modules for serving scripts is the startup, the fork/exec.
Since a large download is dominated by the data transer, not the
startup, there should be little or no harm in using cgi instead of
mod_perl in this case.

> 3. If you use persistant DBI, which is a primary reason to want to use
> mod_perl, it frequently dumps tons of ignorable but extremely annoying
> 'attempt to free unreferenced scalar' messages in your weblogs which
> are very difficult to weed out.
>
> If anyone knows any workarounds to these problems, please let me know
> - but when I have read other people post about them, you can hear
> crickets chirp in response.

I know of nothing to do about number 2 on your list, but for 3, have you
considered upgrading to the most recent version of mod_perl?

That is, perl5.8.0 or 5.8.1, with mod_perl 2.0?

Oh, and upgrading to the most recent version of DBI might also help.

Also, try and figure out approximatly *when* those warnings are being
produced, and just before that happens, install a $SIG{__WARN__} handler
which supresses them, and passes ordinary warnings through.


Another possibility would be to switch from mod_perl to mod_fastcgi or
to mod_persistantperl. Both of these are generally faster than plain
cgi scripts, and I'm quite certain that with mod_fastcgi, you *will*
avoid the "Attempt to free unreferenced scalar" warnings (I'm not sure
whether mod_persistantperl avoids it, though). And, both of them
support persistant database connections.

For both of these alternatives, each "cgi" script actually starts a
mini-server, which the main apache process connects to and communicates
with. To get a modified script to be reloaded, you simply change the
perl script, then kill the mini-server process... which of course is
seperate from the apache process, so killing the mini-server for one
script won't interfere with anything else.

For testing/development purposes, you can easily set each mini-server to
only serve one or two requests and then exit, so you can omit the "kill
the mini-server process" step of making modifications.

--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

[henq]

Seth,
Have you looked at PersistentPerl ? It's brillant. Offers the pre-compiled
advantage but with standard cgi scripts. Allows you to keep DBI handles
alive, don't know about Persistent DBI, though.
~henq




"Seth Brundle" <brundlefly76@hotmail.com> schreef in bericht
news:53e2ec95.0306260825.79680d79@posting.google.c om...

> I have been a perl cgi developer for about 8 years.
> I have been wanting to develop a nice mod_perl system for a long time,
> and recently did.
>
> However, there are some significant drawbacks to mod_perl I have come
> across in production that I wish were explained to people a lot more
> prominantly as drawbacks to mod_perl.
>
> 1. With CGI, production changes are simple: copy the cgi to a
> different filename, make and test changes, and copy it back -
> something broken? revert to earlier copy in less then 1 second. With
> mod_perl, it is much more involved, including renaming not only files
> but module package names within the files (twice) and httpd.conf
> entries, plus server hups. For this reason alone I am converting most
> of my code back to CGI.
>
> With CGI, I never hesitate to jump in and make the most trivial of
> corrections to production code. With mod_perl, I usually let them
> languish until the list is big enough to warrant the procedure.
>
> 2. If you have mod_perl which serves downloads, the downloads will be
> disconnected during a webserver restart (like for log rotation), even
> if it is graceful.
>
> 3. If you use persistant DBI, which is a primary reason to want to use
> mod_perl, it frequently dumps tons of ignorable but extremely annoying
> 'attempt to free unreferenced scalar' messages in your weblogs which
> are very difficult to weed out.
>
> If anyone knows any workarounds to these problems, please let me know
> - but when I have read other people post about them, you can hear
> crickets chirp in response.