Re: problems with module at root of web site
On Wed, 12 Jan 2000, Sean Chittenden wrote: > Mind if I ask a nit-pick of a performance question? Currently > speed and performance are of upmost importance (I'm currently involved in > a mod_perl vs JServ development race). That being said, isn't pushing a > handler onto the request stack slower than predefining a handler that the > request falls through to? I could be wrong and haven't tested things > otherwise, but, it would seem like pushing a custom handler (granted it's > already compiled into byte-code) onto the stack at the time of the request > would take slightly longer. I suppose I'd be who of me to test this > assertion, but if you have any idea as to wether or not this case ahead of > time, I'd be greatly interested in hearing about your past experience. I don't think it would be a measurable difference. the only overhead using push_handlers vs. .conf is: -one Perl method call -growing the Perl*Handler array by 1, if it's not big enough already
Re: problems with module at root of web site
Perrin Harkins wrote: > > Sean Chittenden wrote: > > > > Mind if I ask a nit-pick of a performance question? Currently > > speed and performance are of upmost importance (I'm currently involved in > > a mod_perl vs JServ development race). > > If you're on Linux, I can tell you right now that mod_perl is > significantly faster than the fastest servlet runner > (http://www.caucho.com/) with the fastest JVM (IBM 1.1.8 final > release). If you're on Solaris, all bets are off. I suspect you should > be able to clobber JServ in the performance department on any platform > though. I evaluated mod_perl and JServ solutions for my company, and my initial results showed that mod_perl is 50% faster than JServ on a single processor machine and 70% faster on a dual (Solaris 7, JDK 1.2.1_04). There are a couple of things to consider about JServ, though. One, mod_jserv opens up a whole new socket to the JServ process for each page request. Ouch! (they claim this will be fixed some day). Two, JServ is just plain immature technology. But my theory on why mod_perl runs so much faster is that Solaris (and other Unixes for that matter) probably get a higher level of concurrency with a multiprocess model (multiple httpds each with Perl) rather than a multithreading model (JServ running in a VM). True multithreading under Unix is still a fairly new thing compared to process scheduling. When I passed off my work to the QE department who took ownership of the load testing, they saw the same things I did, but claimed to be able to use the OS and Java to get similar performance to mod_perl. Part of me wonders if they "de-tuned" the kernel to make Perl run worse somehow. The management ended up choosing Java/JSP for the top-of-service web servers, which bothers me because our content providers and production staff simply don't know or use Java, but they use Perl all the time for other tasks. I'm sure the ramifications of their choice will manifest itself in a drastic reduction in time-to-market for web apps and content. :-) In any event, if you're not in a large company and you don't have the resources to spend on tuning your OS and Java runtime for optimal performance, mod_perl is your best bet. It's fast, clean, and flexible. And you get free support right here with this list. :-) Doug
Re: problems with module at root of web site
Sean Chittenden wrote: > > Mind if I ask a nit-pick of a performance question? Currently > speed and performance are of upmost importance (I'm currently involved in > a mod_perl vs JServ development race). If you're on Linux, I can tell you right now that mod_perl is significantly faster than the fastest servlet runner (http://www.caucho.com/) with the fastest JVM (IBM 1.1.8 final release). If you're on Solaris, all bets are off. I suspect you should be able to clobber JServ in the performance department on any platform though. - Perrin
Re: problems with module at root of web site
> "Randal" == Randal L Schwartz <[EMAIL PROTECTED]> writes:
Randal> Or a variation of that, that I like... set up a TransHandler like this:
Randal> sub handler { # PerlTransHandler
Randal> return DECLINED unless $r->uri eq "/";
Randal> $r->set_handler("perl-script");
That should have been ->handler, not ->set_handler. Durn failing memory. :)
Randal> $r->push_handlers( PerlHandler => sub {
Randal> ... your code goes here
Randal> }
Randal> return OK;
And this needs Apache::Constants qw(OK DECLINED);
Randal> }
And I thought it would be obvious that I build my server with
Makefile.PL's "EVERYTHING=1" option by now, but yes, that's a prereq.
--
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!
Re: problems with module at root of web site
> "Sean" == Sean Chittenden <[EMAIL PROTECTED]> writes: Sean> Mind if I ask a nit-pick of a performance question? Currently Sean> speed and performance are of upmost importance (I'm currently involved in Sean> a mod_perl vs JServ development race). That being said, isn't pushing a Sean> handler onto the request stack slower than predefining a handler that the Sean> request falls through to? I could be wrong and haven't tested things Sean> otherwise, but, it would seem like pushing a custom handler (granted it's Sean> already compiled into byte-code) onto the stack at the time of the request Sean> would take slightly longer. I suppose I'd be who of me to test this Sean> assertion, but if you have any idea as to wether or not this case ahead of Sean> time, I'd be greatly interested in hearing about your past experience. I think if you already set the handler, then when it comes to MIME-checking phase, you get a quick no-op. Thus, having the Trans phase set the handler is going to be much faster. My guess. Try it and see. -- 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!
Re: problems with module at root of web site
Mind if I ask a nit-pick of a performance question? Currently
speed and performance are of upmost importance (I'm currently involved in
a mod_perl vs JServ development race). That being said, isn't pushing a
handler onto the request stack slower than predefining a handler that the
request falls through to? I could be wrong and haven't tested things
otherwise, but, it would seem like pushing a custom handler (granted it's
already compiled into byte-code) onto the stack at the time of the request
would take slightly longer. I suppose I'd be who of me to test this
assertion, but if you have any idea as to wether or not this case ahead of
time, I'd be greatly interested in hearing about your past experience.
--Sean
--
Sean Chittenden <[EMAIL PROTECTED]>
On 12 Jan 2000, Randal L. Schwartz wrote:
> Date: 12 Jan 2000 07:33:36 -0800
> From: Randal L. Schwartz <[EMAIL PROTECTED]>
> To: Sean Chittenden <[EMAIL PROTECTED]>
> Cc: Etienne Pelaprat <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: problems with module at root of web site
>
> >>>>> "Sean" == Sean Chittenden <[EMAIL PROTECTED]> writes:
>
> Sean> There are a few ways to go about this one, but here's the solution
> Sean> that I'd use.
>
> Sean> 1) Install a PerlTransHandler that sets the URI to / or whatever
> Sean> you want to have your PerlHandler work with. Have the transhandler return
> Sean> DECLINED if $r->uri =~ m:^/images/:o;
>
> Sean> 2) Install a PerlHandler that builds the response for the web.
>
> Or a variation of that, that I like... set up a TransHandler like this:
>
> sub handler { # PerlTransHandler
> return DECLINED unless $r->uri eq "/";
> $r->set_handler("perl-script");
> $r->push_handlers( PerlHandler => sub {
> ... your code goes here
> }
> return OK;
> }
>
> No need to mess with $r->uri, which will be very confusing if there's
> an error.
>
>
> Sean> The advantage to doing it this way is:
>
> Sean> a) this was what apache was designed for (multiple phases)
> Sean> b) allows other handlers to kick in before you build the response
> Sean> (such as mod_access)
>
> Absolutely.
>
>
Re: problems with module at root of web site
> "Sean" == Sean Chittenden <[EMAIL PROTECTED]> writes:
Sean> There are a few ways to go about this one, but here's the solution
Sean> that I'd use.
Sean> 1) Install a PerlTransHandler that sets the URI to / or whatever
Sean> you want to have your PerlHandler work with. Have the transhandler return
Sean> DECLINED if $r->uri =~ m:^/images/:o;
Sean> 2) Install a PerlHandler that builds the response for the web.
Or a variation of that, that I like... set up a TransHandler like this:
sub handler { # PerlTransHandler
return DECLINED unless $r->uri eq "/";
$r->set_handler("perl-script");
$r->push_handlers( PerlHandler => sub {
... your code goes here
}
return OK;
}
No need to mess with $r->uri, which will be very confusing if there's
an error.
Sean> The advantage to doing it this way is:
Sean> a) this was what apache was designed for (multiple phases)
Sean> b) allows other handlers to kick in before you build the response
Sean> (such as mod_access)
Absolutely.
--
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!
Re: problems with module at root of web site
> I have written a perl module that is meant to run at the root of a web > site (blah.com/, let's say), but there are errors whenever it tries to > access an image with an absolute URL. For instance, this tag returns a > broken image: > > > > this, I'm guessing, is because it's using in some way or another the > module I have written, since it's pointing from root. How do I fix > this? How do I make the module act at the root of the site and not > have it interfere with absolute URIs like that? How about reading the error messages from the error_log file? See: http://perl.apache.org/guide/debug.html for more info. ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: problems with module at root of web site
There are a few ways to go about this one, but here's the solution that I'd use. 1) Install a PerlTransHandler that sets the URI to / or whatever you want to have your PerlHandler work with. Have the transhandler return DECLINED if $r->uri =~ m:^/images/:o; 2) Install a PerlHandler that builds the response for the web. The advantage to doing it this way is: a) this was what apache was designed for (multiple phases) b) allows other handlers to kick in before you build the response (such as mod_access) -- Sean Chittenden <[EMAIL PROTECTED]> Power tends to corrupt, absolute power corrupts absolutely. -- Lord Acton On Wed, 12 Jan 2000, Etienne Pelaprat wrote: > Date: Wed, 12 Jan 2000 01:50:49 PST > From: Etienne Pelaprat <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: problems with module at root of web site > > Hi, > > I have written a perl module that is meant to run at the root of a web > site (blah.com/, let's say), but there are errors whenever it tries to > access an image with an absolute URL. For instance, this tag returns a > broken image: > > > > this, I'm guessing, is because it's using in some way or another the > module I have written, since it's pointing from root. How do I fix > this? How do I make the module act at the root of the site and not > have it interfere with absolute URIs like that? > > Regards, > > Etienne >
problems with module at root of web site
Hi, I have written a perl module that is meant to run at the root of a web site (blah.com/, let's say), but there are errors whenever it tries to access an image with an absolute URL. For instance, this tag returns a broken image: this, I'm guessing, is because it's using in some way or another the module I have written, since it's pointing from root. How do I fix this? How do I make the module act at the root of the site and not have it interfere with absolute URIs like that? Regards, Etienne
