You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2001/08/31 01:44:00 UTC
Re: 2.0.26?]
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Thursday, August 30, 2001 6:34 PM
> From: "Ian Holsman" <ia...@cnet.com>
> Sent: Thursday, August 30, 2001 5:42 PM
> >
> > the only thing 'funny' I'm noticing is that the map_to_storage hook
> > isn't getting called for a sub-request.. this may be my code
> > I just noticed that 10 minutes ago,
> > I'm still investigating it.
>
> That would be a problem. It doesn't surprize me either. Every month I go back over the
> discrepancies in the internal_internal_redirect v.s. ap_process_request v.s. all the
> other ways we set up redirects/subrequests.
>
> These distinctions have to go away. Not that the steps can't be _heavily_ optimized
> by looking at r->prev or r->main for clues, but we need a single code path through
> this potentially tricky code.
>
> Notice all the fooness in the subreq mechanisms "Hey, if this, then we don't need to
> do that!" All well and good until some module gets hurt ;) If the authn/authz module
> _itself_ peeked at the pool data for r->main->p, "my_own_cache" and sees it's being
> redundant, it pulls a fast exit (fast OK, fast DECLINED, or fast HTTP_NOT_AUTHORIZED.)
>
> There is probably another weeks worth of work in optimizing these modules (see the
> ap_location_walk function for such an example.) Then all these code paths can be folded
> into a single place.
The other option is that we patch these to a single code path _today_. Let Apache run a
bit slow until these optimizations are moved into the right, magic places.
Thoughts?
Bill
Re: 2.0.26?]
Posted by Cliff Woolley <cl...@yahoo.com>.
On 30 Aug 2001, Ian Holsman wrote:
> > > There is probably another weeks worth of work in optimizing these
> > > modules (see the ap_location_walk function for such an example.)
> > > Then all these code paths can be folded into a single place.
> >
> > The other option is that we patch these to a single code path
> > _today_. Let Apache run a bit slow until these optimizations are
> > moved into the right, magic places.
> >
> I think that would make more sense.
+1
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?]
Posted by Ian Holsman <Ia...@cnet.com>.
On Thu, 2001-08-30 at 16:44, William A. Rowe, Jr. wrote:
> From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> Sent: Thursday, August 30, 2001 6:34 PM
>
>
> > From: "Ian Holsman" <ia...@cnet.com>
> > Sent: Thursday, August 30, 2001 5:42 PM
> > >
> > > the only thing 'funny' I'm noticing is that the map_to_storage hook
> > > isn't getting called for a sub-request.. this may be my code
> > > I just noticed that 10 minutes ago,
> > > I'm still investigating it.
> >
> > That would be a problem. It doesn't surprize me either. Every month I go back over the
> > discrepancies in the internal_internal_redirect v.s. ap_process_request v.s. all the
> > other ways we set up redirects/subrequests.
> >
> > These distinctions have to go away. Not that the steps can't be _heavily_ optimized
> > by looking at r->prev or r->main for clues, but we need a single code path through
> > this potentially tricky code.
> >
> > Notice all the fooness in the subreq mechanisms "Hey, if this, then we don't need to
> > do that!" All well and good until some module gets hurt ;) If the authn/authz module
> > _itself_ peeked at the pool data for r->main->p, "my_own_cache" and sees it's being
> > redundant, it pulls a fast exit (fast OK, fast DECLINED, or fast HTTP_NOT_AUTHORIZED.)
> >
> > There is probably another weeks worth of work in optimizing these modules (see the
> > ap_location_walk function for such an example.) Then all these code paths can be folded
> > into a single place.
>
> The other option is that we patch these to a single code path _today_. Let Apache run a
> bit slow until these optimizations are moved into the right, magic places.
>
I think that would make more sense.
> Thoughts?
>
> Bill
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608