It's all in little gains, we have some site like example.fr, example.com, sub.example.fr that in fact runs to the same directory. Doing this (the balance on host header) help the efficiency of the whole system, the 'use_domain_only' is just a potential small gain but if a small bit of code can potentially reduce the backend load why not ?

As for the "apache instance with virtual hosting", i don't see your point here. Our backend server are apache server, with mod_rewrite based virtualhost to allow easier update of the domain to directory mapping and an application servers.

There is file caching on the system side, on the application server side and just doing that
reduce by two to three the average response time of a page.


Ah, okay, I see. Thanks for the clarification. Caching is where I saw something like this coming in handy---my other comment was something like, caching aside, why would we care how the requests are distributed over instances where users are likely to not use all of the domains/tlds? Like, if I am reading the english version of a page, I likely speak English and won't do something like flip over to the French version, thusly I would never get to take advantage of this option. But in the case of caching assets, yes, I do see the point. Neat.


John L. Singleton
jsing...@gmail.com



On Mar 29, 2009, at 1:33 PM, benoit wrote:


It's all in little gains, we have some site like example.fr, example.com, sub.example.fr that in fact runs to the same directory. Doing this (the balance on host header) help the efficiency of the whole system, the 'use_domain_only' is just a potential small gain but if a small bit of code can potentially reduce the backend load why not ?

As for the "apache instance with virtual hosting", i don't see your point here. Our backend server are apache server, with mod_rewrite based virtualhost to allow easier update of the domain to directory mapping and an application servers.

There is file caching on the system side, on the application server side and just doing that
reduce by two to three the average response time of a page.

John L. Singleton a écrit :
I'm a little mystified as to the usefulness of this as well. I mean, what does hashing the domain name solve that just balancing back to a bunch of Apache instances with virtual hosting turned on doesn't? Are you saying that you have domains like en.example.com, fr.example.com and you want them all to be sticky to the same backend server when they balance? If that's the case, I could see that being useful if the site in question were doing some sort of expensive per-user asset generation that was being cached on the server. Is this what you are talking about?


John L. Singleton
jsing...@gmail.com <mailto:jsing...@gmail.com>




On Mar 29, 2009, at 9:05 AM, Jeffrey 'jf' Lim wrote:

On Wed, Mar 25, 2009 at 8:02 PM, Benoit <maver...@maverick.eu.org <mailto:maver...@maverick.eu.org >> wrote:


diff -ru haproxy-1.3.15.7/doc/configuration.txt haproxy-1.3.15.7- cur/doc/configuration.txt --- haproxy-1.3.15.7/doc/configuration.txt 2008-12-04 11:29:13.000000000 +0100 +++ haproxy-1.3.15.7-cur/doc/configuration.txt 2009-02-24 16:17:19.000000000 +0100
@@ -788,6 +788,19 @@

               balance url_param <param> [check_post [<max_wait>]]

+ header The Http Header specified in argument will be looked up in
+                  each HTTP request.
+
+ With the "Host" header name, an optionnal use_domain_only + parameter is available, for reducing the hash algorithm to + the main domain part, eg for "haproxy.1wt.eu", only "1wt"
+                  will be taken into consideration.
+

I'm not so sure how balancing based on a hash of the Host header would
be useful. How would this be useful? I would see an application for
balancing on perhaps other headers (like xff as mentioned), but for
Host... I dunno... (so basically what I'm saying is, is the code for
the 'use_domain_only' bit useful? can it be left out?)

-jf

--
In the meantime, here is your PSA:
"It's so hard to write a graphics driver that open-sourcing it would not help."
  -- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228






Reply via email to