Re: CGI scripts & mod_perl
On Mon, 20 Nov 2000, Gunther Birznieks wrote: > Most normal applications do not require every bit of speed eeked out > of them that may be possible with an Apache handler. In the mod_perl > guide, a reasonably fast machine (which most production mod_perl sites > run on) shows very little time difference between a real-world app > (what I would categorize the heavy Apache::Registry vs heavy hander) > running in Apache::Registry versus being written as a handler. We've already discussed this one into the ground, but for anyone here who hasn't heard all this before, the main reason to use handlers instead of Registry is to avoid the odd compromises caused by writing something that is going to be wrapped in a generated package name and eval'ed into a subroutine. It's a pretty cool trick, but it's also limiting. For example, not being able to use subroutines unless you put them in an external module is troublesome. I also use handlers invoked as class methods so that I can do some inheritance stuff in my modules. I don't think Apache::Registry can deal with that at this point. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts & mod_perl
> "GB" == Gunther Birznieks <[EMAIL PROTECTED]> writes: GB> Apache::Registry programs are basically compatible with Velocigen, GB> PerlEx, and SpeedyCGI acceleration. I think that's a huge GB> commercial and open source advantage for anyone writing web GB> programs for sale or open community use. And most of them can still run as traditional fork/exec CGI's for the occasion where you need to use it on another server. I think I've written exactly *one* direct handler (other than for hire), and that was just for learning how to do it. I use Registry all the time and see no reason not to continue using it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts & mod_perl
At 03:04 PM 11/19/2000 -0800, Randal L. Schwartz wrote:
> > "Didier" == Didier Godefroy <[EMAIL PROTECTED]> writes:
>
>Didier> on 11/19/00 4:55 PM, Ime Smits at [EMAIL PROTECTED] uttered the following:
> >> | How do we make sure regular CGI scripts are using mod_perl???
> >> | Is there a way to find out?
> >>
> >> Check $ENV{MOD_PERL}, it should read something like "mod_perl/1.24".
>
>Didier> Can I assume that whenever mod_perl is enabled that all existing perl
>Didier> scripts use it without any modification of any kind?
>
>Not at all. Apache::Registry is a good stop-gap, but you have to play
>by a number of useful and documented rules.
>
>When you're *really* good with mod_perl, you abandon Apache::Registry
>and move up to writing handlers or using embedded templating systems
>like EmbPerl, Mason, or Template Toolkit.
I do not consider Apache::Registry a stop gap. Maybe something like
Apache::PerlRun is. The "rules" that you have to play by are also quite
similar to the rules you would have to play by when writing a handler anyway.
Apache::Registry programs are basically compatible with Velocigen, PerlEx,
and SpeedyCGI acceleration. I think that's a huge commercial and open
source advantage for anyone writing web programs for sale or open community
use.
Most people who write applications that require the use of mod_perl as
opposed to using mod_perl as an option are shooting themselves in the foot
as much as people who write applications that can only run in CGI
mode. There are occasional exceptions of course (eg AxKit makes reasonable
use of Apache as a low-level system).
Most normal applications do not require every bit of speed eeked out of
them that may be possible with an Apache handler. In the mod_perl guide, a
reasonably fast machine (which most production mod_perl sites run on) shows
very little time difference between a real-world app (what I would
categorize the heavy Apache::Registry vs heavy hander) running in
Apache::Registry versus being written as a handler.
The use of Apache::args and Apache::Request::param seem to provide a better
bet for the code optimization money than simply moving out of
Apache::Registry to a handler().
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts & mod_perl
Find the time to READ the documentation Tonight would be a good nite. Ruben http://www.mrbrklyn.com > At the moment, I'm just trying to get mod_perl to work and have users' > scripts use it. I haven't had time to read docs on how to use it, only > enough to get it going. > Will it speed up regular scripts? > Will it reduce the strain on system resources? > Can I force existing scripts to use it with only a section? without > modifying any scripts? > How can I get confirmation that scripts are actually using it > > -- > Didier Godefroy > mailto:[EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts & mod_perl
> > When you're *really* good with mod_perl, you abandon Apache::Registry > and move up to writing handlers or using embedded templating systems > like EmbPerl, Mason, or Template Toolkit. Actually, if your using EMBPERL, why even BOTHER with the CGI interface at all. But I think that EMBPERL uses CGI.pm. I generally teach CGI for ten minutes and then jump straight into therorical Mod_perl and into Practical EMBPERL. Ruben http://www.mrbrklyn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts & mod_perl
on 11/19/00 6:04 PM, Randal L. Schwartz at [EMAIL PROTECTED] uttered the following: > Didier> Can I assume that whenever mod_perl is enabled that all existing perl > Didier> scripts use it without any modification of any kind? > > Not at all. Apache::Registry is a good stop-gap, but you have to play > by a number of useful and documented rules. > > When you're *really* good with mod_perl, you abandon Apache::Registry > and move up to writing handlers or using embedded templating systems > like EmbPerl, Mason, or Template Toolkit. At the moment, I'm just trying to get mod_perl to work and have users' scripts use it. I haven't had time to read docs on how to use it, only enough to get it going. Will it speed up regular scripts? Will it reduce the strain on system resources? Can I force existing scripts to use it with only a section? without modifying any scripts? How can I get confirmation that scripts are actually using it -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts & mod_perl
> "Didier" == Didier Godefroy <[EMAIL PROTECTED]> writes:
Didier> on 11/19/00 4:55 PM, Ime Smits at [EMAIL PROTECTED] uttered the following:
>> | How do we make sure regular CGI scripts are using mod_perl???
>> | Is there a way to find out?
>>
>> Check $ENV{MOD_PERL}, it should read something like "mod_perl/1.24".
Didier> Can I assume that whenever mod_perl is enabled that all existing perl
Didier> scripts use it without any modification of any kind?
Not at all. Apache::Registry is a good stop-gap, but you have to play
by a number of useful and documented rules.
When you're *really* good with mod_perl, you abandon Apache::Registry
and move up to writing handlers or using embedded templating systems
like EmbPerl, Mason, or Template Toolkit.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts & mod_perl
on 11/19/00 4:55 PM, Ime Smits at [EMAIL PROTECTED] uttered the following:
> | How do we make sure regular CGI scripts are using mod_perl???
> | Is there a way to find out?
>
> Check $ENV{MOD_PERL}, it should read something like "mod_perl/1.24".
Can I assume that whenever mod_perl is enabled that all existing perl
scripts use it without any modification of any kind?
I tried this in a simple script on both systems where I installed mod_perl
and there is nothing in that variable on either system.
Isn't there any way to find out if mod_perl actually works?
I see nothing special in any logs about this, but a status and info on
apache shows mod_perl enabled, and the few perl directives I inserted in the
httpd.conf aren't making a fuss, so I assume mod_perl is parsing them
properly...
--
Didier Godefroy
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI scripts & mod_perl
| How do we make sure regular CGI scripts are using mod_perl???
| Is there a way to find out?
Check $ENV{MOD_PERL}, it should read something like "mod_perl/1.24".
Ime
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
CGI scripts & mod_perl
Quick (and maybe stupid) question(s): How do we make sure regular CGI scripts are using mod_perl??? Is there a way to find out? Is there anything to modify to make them work with mod_perl?? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
