You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/03/14 01:00:53 UTC
the deprecation of Apache->request in mp2
One more issue with CGI.pm and mp2, and other modules as well.
CGI.pm is using Apache->request. The setting/retrieval of the global request
record under threads is expensive, so the use of Apache->request is deprecated
in mp2.
If CGI.pm can be changed to optionally accept $r (as an argument to new(),
plus a special accessor to set later) and use it instead, this will improve
the performance if Apache->request is not set.
Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by
default with 'SetHandler perl-script') that is half of the performance hit
(store), and the actual use of Apache->request (get) is the second half.
See:
http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_request_
http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the deprecation of Apache->request in mp2
Posted by Lincoln Stein <ls...@cshl.org>.
I suppose there might be name clashes, but I'll look into doing that.
Lincoln
On Monday 24 March 2003 07:08 pm, Stas Bekman wrote:
> Lincoln Stein wrote:
> >>How about making CGI.pm a subclass of $r? (optionally of course, by
> >>dynamically changing @ISA), so instead of returning $q it'll return $r,
> >>after re-blessing it.
> >
> > Sounds interesting. What would be the advantage of that?
>
> The advantage is that
> - you don't have to keep around two instances: $r and $q.
> - assuming that CGI.pm-specific code is not used one can transparently
> switch between Apache::Request and CGI.pm, by just changing:
>
> $r = Apache::Request->new($r);
> $r = CGI->new($r);
>
> And of course Apache::Request is a subclass of Apache ($r) and it works
> pretty well.
>
> In the future I can see someone extending Apache::Request to handle
> CGI.pm's HTML generation in C, so the two could be replace each other.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: the deprecation of Apache->request in mp2
Posted by Andrew Ho <an...@tellme.com>.
Hello,
NT>I sure hope not! I second John Siracusa's post on this. Keep the HTML
NT>generation well away from request parsing, please!
I personally am 100% in the camp of keeping HTML generation separate from
quest parsing, but I do recognize the advantage of having API level
compatibility between Apache::Request and CGI, so that you could switch
from one to another easily. I think this would be a big win for mod_perl
overall from the "port your scripts quickly" point of view.
I think a good compromise would be to keep the HTML generation code in an
entirely separate module, like Apache::Request::HTML or something. That
class could augment Apache::Request with new methods. (This is somewhat
similar to how Apache::File and Apache::Log augment the Apache class with
new methods.)
This seems to satisfy both sides, and accomplish the laudable goal of
making CGI and Apache::Request API compatible without bloating up the
normal use of Apache::Request.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer 1-800-555-TELL Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
----------------------------------------------------------------------
Re: the deprecation of Apache->request in mp2
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Tue, 25 Mar 2003, Stas Bekman wrote:
> Lincoln Stein wrote:
> >>How about making CGI.pm a subclass of $r? (optionally of course, by
> >>dynamically changing @ISA), so instead of returning $q it'll return $r,
> >>after re-blessing it.
> >
> >
> > Sounds interesting. What would be the advantage of that?
>
> The advantage is that
> - you don't have to keep around two instances: $r and $q.
> - assuming that CGI.pm-specific code is not used one can transparently switch
> between Apache::Request and CGI.pm, by just changing:
>
> $r = Apache::Request->new($r);
> $r = CGI->new($r);
>
> And of course Apache::Request is a subclass of Apache ($r) and it works pretty
> well.
>
> In the future I can see someone extending Apache::Request to handle CGI.pm's
> HTML generation in C, so the two could be replace each other.
I sure hope not! I second John Siracusa's post on this. Keep the HTML generation well away from request parsing, please!
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
Re: the deprecation of Apache->request in mp2
Posted by John Siracusa <si...@mindspring.com>.
On 3/24/03 7:08 PM, Stas Bekman wrote:
> In the future I can see someone extending Apache::Request to handle CGI.pm's
> HTML generation in C, so the two could be replace each other.
I've always thought that HTML generation does not belong in CGI.pm, so I
don't see duplicating that functionality in an extended $r as a useful goal.
Better to separate the HTML stuff (preferably into HTML widget objects, IMO)
from request parsing and response formulation and delivery.
-John
Re: the deprecation of Apache->request in mp2
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
>>How about making CGI.pm a subclass of $r? (optionally of course, by
>>dynamically changing @ISA), so instead of returning $q it'll return $r,
>>after re-blessing it.
>
>
> Sounds interesting. What would be the advantage of that?
The advantage is that
- you don't have to keep around two instances: $r and $q.
- assuming that CGI.pm-specific code is not used one can transparently switch
between Apache::Request and CGI.pm, by just changing:
$r = Apache::Request->new($r);
$r = CGI->new($r);
And of course Apache::Request is a subclass of Apache ($r) and it works pretty
well.
In the future I can see someone extending Apache::Request to handle CGI.pm's
HTML generation in C, so the two could be replace each other.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the deprecation of Apache->request in mp2
Posted by Lincoln Stein <ls...@cshl.org>.
> How about making CGI.pm a subclass of $r? (optionally of course, by
> dynamically changing @ISA), so instead of returning $q it'll return $r,
> after re-blessing it.
Sounds interesting. What would be the advantage of that?
Lincoln
>
> > The other issue is that it will only work with the OO form of CGI, which
> > many people (including myself) don't use.
>
> You can still have an accessor function to set $r:
>
> use CGI;
> CGI->r($r);
>
> > I would prefer a more transparent way to obtain the current request. Is
> > there no low-overhead way of getting at this?
>
> Not, under threaded mpm. Since the code should work the same with threaded
> and non-threaded mpm, it's a problem for any 2.0 code. The problem with
> Apache->request is that it involves storing and retrieving data from the
> TLS (thread local storage), which is slow. So while the functionality is
> there, sites that are looking for high performance will want to pass $r,
> rather than rely on Apache->request.
>
> Of course one can argue, that sites looking for high performance should use
> Apache::Request (which is not quite there yet, for 2.0). So if this
> argument is valid and you don't feel like changing the API, that's cool
> too. May be in the future.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: the deprecation of Apache->request in mp2
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
> I can do this (changing the new() call to accept $r). My understanding is
> that client code will need to be changed to take advantage of this, right?
That's correct. $r should be explicitly passed. However the CGI-side code
doesn't have to specific to mod_perl 2.0. CGI should be able to do that with
either version of mod_perl. In this case the user code can be ported to work
with both versions of mod_perl.
How about making CGI.pm a subclass of $r? (optionally of course, by
dynamically changing @ISA), so instead of returning $q it'll return $r, after
re-blessing it.
> The other issue is that it will only work with the OO form of CGI, which many
> people (including myself) don't use.
You can still have an accessor function to set $r:
use CGI;
CGI->r($r);
> I would prefer a more transparent way to obtain the current request. Is there
> no low-overhead way of getting at this?
Not, under threaded mpm. Since the code should work the same with threaded and
non-threaded mpm, it's a problem for any 2.0 code. The problem with
Apache->request is that it involves storing and retrieving data from the TLS
(thread local storage), which is slow. So while the functionality is there,
sites that are looking for high performance will want to pass $r, rather than
rely on Apache->request.
Of course one can argue, that sites looking for high performance should use
Apache::Request (which is not quite there yet, for 2.0). So if this argument
is valid and you don't feel like changing the API, that's cool too. May be in
the future.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the deprecation of Apache->request in mp2
Posted by Lincoln Stein <ls...@cshl.org>.
I can do this (changing the new() call to accept $r). My understanding is
that client code will need to be changed to take advantage of this, right?
The other issue is that it will only work with the OO form of CGI, which many
people (including myself) don't use.
I would prefer a more transparent way to obtain the current request. Is there
no low-overhead way of getting at this?
Lincoln
On Thursday 13 March 2003 07:00 pm, Stas Bekman wrote:
> One more issue with CGI.pm and mp2, and other modules as well.
>
> CGI.pm is using Apache->request. The setting/retrieval of the global
> request record under threads is expensive, so the use of Apache->request is
> deprecated in mp2.
>
> If CGI.pm can be changed to optionally accept $r (as an argument to new(),
> plus a special accessor to set later) and use it instead, this will improve
> the performance if Apache->request is not set.
>
> Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by
> default with 'SetHandler perl-script') that is half of the performance hit
> (store), and the actual use of Apache->request (get) is the second half.
>
> See:
> http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_reque
>st_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================