tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Sexton" <gsex...@mhsoftware.com>
Subject RE: Code Submission - Wild Card Aliases
Date Wed, 04 May 2005 17:23:38 GMT
Rémy,

I'll look at those. So far, I re-wrote the algorithm, and I've got it
improved.

The old algorithm (5.5.9) takes 8772 ms on a P3 600 ( My earlier timed
reports were approximate but relative).

My current version of the algorithm taks 7383 ms. This is for the million
iterations with about 15 hosts, and 6 or so contexts. The improvement for 1
million iterations is 1389 milli-seconds, or about 15%. I suspect most of
the remaining time is in the context lookup now.

The current algorithm is using a parallel int array of hash codes which it
uses to quickly find (using Arrays.binarySearch(int[],int)) the array
element, and then it does a string comparison using the
CharChunk.equalsIgnoreCase() method for the final comparison. I have handled
the possibility of collision in the hash usage, so that is not a concern.

I believe the slow down in my initial attempt was not caused by the HashMap,
but caused by the call to CharChunk.toString() and the corresponding
toLowerCase() to get the key.

As far as feature bloat goes, that's relative. I look at some of the current
features and think "That must be a one in a thousand installations
thing...". An example that comes to mind is the proxying support. It comes
down to what the person using it is doing. In my case, I'm hosting 40
virtual hosts in one instance, on one machine (a P3 600). In the near
future, I'm probably going to be adding 5-10 virtual hosts per month. I'm
hoping that I'll be able to scale to 200 virtual hosts per (newer, faster)
server.

The feature in my software that I need wild card aliases for is this: We
have a calendar application. Large customers with many calendars are not
comfortable with the sheer number of calendars that show to the public, or
they want to have one set of calendars show to one group of public users,
while another set of calendars show to another set of public users. Our
solution was to select the public calendars based on the virtual host name
of the request. In this way, training.foo.com would have one set of
calendars, while marketing_events.foo.com can have a different set of public
calendars. Without wild-card aliases, I have to manually add each alias they
want to use to tomcat, and re-start the engine. This would be painful for
larger customers.

Out of my 40 current customers, about 4 are going to immediately start using
the virtual host feature in my software.




George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  

> -----Original Message-----
> From: Remy Maucherat [mailto:remm@apache.org] 
> Sent: Wednesday, May 04, 2005 5:45 AM
> To: Tomcat Developers List
> Subject: Re: Code Submission - Wild Card Aliases
> 
> George Sexton wrote:
> > Let me see what I can do.
> 
> So that I don't get a too bad reputation, here's an algorithm idea I 
> thought about:
> - first, why use *.foo.com ? I'd say .foo.com is better (the 
> algo will 
> use it)
> - use a separate array for wildcard host names, where they are stored 
> reversed (ex: moc.oof).
> - after doing the regular lookup, do a lookup in the wildcard 
> host array 
> (same as wildcard servlet mapping), but using the reversed host 
> (findIgnoreCaseReverse or something) where you start with the 
> last char
> - if the int returned corresponds to something which "starts with" 
> (reversed) with your host, then it's the best match
> 
> This way:
> - if there are no wildcard hosts, the cost is zero (the array 
> will be empty)
> - you get nesting for free (ex: .private.foo.com and .foo.com
> - you don't need to add hosts to the main host array
> - you get to code funny algorithms during work hours, which IMO beats 
> doing Struts form beans (YMMV)
> 
> I still think the feature is borderline bloat, though ... :(
> 
> Rémy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message