You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Ralf S. Engelschall" <rs...@engelschall.com> on 1998/02/14 20:00:49 UTC

Re: mod_rewrite \(was Re: 1.2.6\)

In article <XF...@unix-ag.org> you wrote:
> According to Dean Gaudet:

>>  Yuck, I wasn't even aware of this brokenness in mod_userdir.  I personally
>>  wish we'd just dropped mod_userdir et al for mod_rewrite ages ago.  But
>>  whatever.  I'll go put a bandaid on it. 

> Is there a reason why mod_userdir and mod_alias are still in use?
> mod_rewrite can easily replace both modules and writing some
> wrapper functions to provide backward compatibility to the userdir
> and alias directives shouldn't be a problem. In fact Ralf demonstrated
> that this is possible some time ago with his mod_rewrite_compat module...

Yes, this module mod_rewrite_compat.c could be updated and will work fine, I
think. But as Ken said, some users driving small and fast Apaches perhaps
don't like the overhead of the regex matches. Has someone performance values
which actually say that the regex matches are _dramatically_ slower then using
a substring match in practice?

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Re: mod_rewrite \(was Re: 1.2.6\)

Posted by Dean Gaudet <dg...@arctic.org>.
No, I doubt it would.  My comment is that the translation phase isn't
where we're wasting our time right now, we spend time in I/O and we spend
time in strcasecmp() (due to tables) and we spend time in poorly coded
main/util.c routines.  Fix those and then yeah maybe we'll have to tune
mod_rewrite next. 

Dean

On Sun, 15 Feb 1998, Rodent of Unusual Size wrote:

> Dean Gaudet wrote:
> > 
> >          I don't think the various translation modules are speed
> > problems for most folks.
> 
> But what if the translation was being done my mod_rewrite for all
> ~user and alias (and presumably scriptalias) requests?  Would it
> have a performance impact then versus mod_alias and mod_userdir?
> 
> #ken	P-)}
> 


Re: mod_rewrite \(was Re: 1.2.6\)

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
> 
>          I don't think the various translation modules are speed
> problems for most folks.

But what if the translation was being done my mod_rewrite for all
~user and alias (and presumably scriptalias) requests?  Would it
have a performance impact then versus mod_alias and mod_userdir?

#ken	P-)}

Re: mod_rewrite \(was Re: 1.2.6\)

Posted by Dean Gaudet <dg...@arctic.org>.
If I found regex substitution to be a problem on my server I would write
mod_rewrite_flex which includes a full flex parser to parse URLs as fast
as they damn well could be ;)  Nothing like parsing all of your regexs in
parallel.  I don't think the various translation modules are speed
problems for most folks. 

Dean

On Sat, 14 Feb 1998, Ralf S. Engelschall wrote:

> 
> In article <XF...@unix-ag.org> you wrote:
> > According to Dean Gaudet:
> 
> >>  Yuck, I wasn't even aware of this brokenness in mod_userdir.  I personally
> >>  wish we'd just dropped mod_userdir et al for mod_rewrite ages ago.  But
> >>  whatever.  I'll go put a bandaid on it. 
> 
> > Is there a reason why mod_userdir and mod_alias are still in use?
> > mod_rewrite can easily replace both modules and writing some
> > wrapper functions to provide backward compatibility to the userdir
> > and alias directives shouldn't be a problem. In fact Ralf demonstrated
> > that this is possible some time ago with his mod_rewrite_compat module...
> 
> Yes, this module mod_rewrite_compat.c could be updated and will work fine, I
> think. But as Ken said, some users driving small and fast Apaches perhaps
> don't like the overhead of the regex matches. Has someone performance values
> which actually say that the regex matches are _dramatically_ slower then using
> a substring match in practice?
> 
> Greetings,
>                                        Ralf S. Engelschall
>                                        rse@engelschall.com
>                                        www.engelschall.com
>