httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [2.0] proposed vhost config rewrite
Date Mon, 09 Jun 1997 16:54:18 GMT
Well it is possible to optimize in a less-rigid scheme.  Provided it's
easy to detect "things that look like select() in C".  Like if you see:

<if ip_addr == foo_1 or ip_addr == foo_2>
<else if ip_addr == foo_3 >
<else>
<endif>

That's hashable.  You can put whatever you want inside.  The system then
just interprets multiple levels of hashes in any order... but if you
see:

<if ip_port == blah and ip_addr == foo_1>
<else if ip_addr == foo_2>
<else>
<endif>

well, tough, you won't get hashing optimizations.

The ease of detecting those constructs depends greatly on what internal
structure you're using to represent them.

We can provide the generality and optimize code for "high end" systems.
There's essentially two basic categories:

- systems where everything is ip-based, easy to optimize

- systems with large numbers of named-based hosts where the names match
    the regex (^|\.)foobar\.dom$  (actually we really don't want to allow
    regexs... it's possible to do a good hash if we allow .foobar.dom to
    match *.foobar.dom and foobar.dom itself catching 99% of the cases)

The first case is dedicated web servers, and webservers of "high paying"
customers at ISPs.  The second case is likely low paying customers, but
the servers will have many many vhosts.  The second case also usually has
ServerPath gunk thrown in ... but I still think we can detect it all and
optimize.
    
It's even possible to combine the two and optimize if we say "always
nest name-based matching inside ip-based matching for best performance".

So yeah it's possible to do a general solution, it just means more effort
for optimizing (have to detect the construct).  People whose servers
don't match our optimizations get the current level of performance.

Dean

On Mon, 9 Jun 1997, Ben Laurie wrote:

> Dean Gaudet wrote:
> > <PortMatch PP ...>
> >     ...
> >     <IPMatch a.b.c.d ...>
> > 	...
> > 	<HostMatch ... ...>
> > 	    ...
> > 	</HostMatch>
> > 	...
> >     </IPMatch>
> >     ...
> > <PortMatch>
> 
> Interesting - the scheme I'm toying with looks a bit like this, only more so -
> you can nest them in any order, there's <else>s, there's things like URLMatch,
> and so on...
> 
> However, it wouldn't be quite so efficient as the more rigid scheme you are
> proposing (maybe).
> 
> Cheers,
> 
> Ben.
> 
> -- 
> Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
> Freelance Consultant and  Fax:   +44 (181) 994 6472
> Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
> A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
> London, England.          Apache-SSL author
> 


Mime
View raw message