-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark,

On 3/15/2011 6:02 AM, Mark Thomas wrote:
> On 15/03/2011 06:06, Jason Pringle wrote:
>> Clearly what is there is correct, since it takes some extra effort to embed 
>> a Host header into the HTTP request if you don't have a DNS entry (messing 
>> with /etc/hosts would be one way).  But that last bit of info for how Tomcat 
>> actually makes use of the header would be handy in the docs (I know - 
>> patches welcome :))
> 
> I took a stab at improving the docs. You can read the results here.
> http://ci.apache.org/projects/tomcat/tomcat7/docs/config/host.html
> And yes, patches/suggested changes welcome.
> 
>> Is there any measurable performance optimization of using the name of the 
>> host that is expected to be in the request?  I would guess not, even for a 
>> very high volume site, but haven't looked at the code.
> 
> There is a very, very small gain. I doubt it it measurable.

I haven't looked in-deptch at the mapper, but I was thinking that there
could be some performance optimizations for certain cases. I'm not sure
such optimizations would be measurable but they are fortunately easy to
test.

For instance, I guess the hostnames are stored in a Map keyed on
lowercase hostname, and each request does a lookup in that Map to
determine the host that will handle the request. If the result is null,
you choose the defaulHost.

If, on startup, we used a pluggable host mapper, we would optimize for
certain cases:

* Only one host, which is the default
  - no case-normalization or lookup required: the one host is always
    the right host
* Only 2 or 3 (or whatever) hosts
  - use if/then to test a small number of host names directly instead
    of hashing, etc. (similar to using commons-collections Flat3Map)
* All other cases: use existing strategy

There are a couple of potential problems with this:

1. Added code complexity... have to determine how much performance gain
   (if any) this complexity adds
2. Interferes with dynamic host add/remove code, though that could be
   handled as well
3. Problems often come in 3s :)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1/f08ACgkQ9CaO5/Lv0PABcQCffRKyaBwFPpMunEiWga6AHnEL
Xb0AoK5saev3ySVzobnnwQHBs9ibcsHZ
=6orN
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to