Hypermail

From: Benoit <maverick#maverick.eu.org>
Date: Tue, 27 Nov 2007 10:08:04 +0100

Willy Tarreau a écrit :
> On Mon, Nov 26, 2007 at 11:35:45PM +0100, Benoit wrote:
>

>> Willy Tarreau a écrit :
>>     
>>> On Mon, Nov 26, 2007 at 09:44:25PM +0100, Benoit wrote:
>>>  
>>>
>>> OK I understand what you want. Currently we don't do that. It's not
>>> hard to implement, at least for the easiest part which would consist
>>> in header hashing, and it's planned for a later version, when core
>>> features will have settled down.
>>>
>>> A more complete solution will involve stickiness on anything, including
>>> headers or url parameters. But I really, really suggest that you go for
>>> hashing instead of stickiness.
>>>
>>> Right now, if your number of hosts is really limited, maybe you can
>>> simply write a few ACLs and statically assign each of them to one
>>> server ?
>>>  
>>>       
>> Well, i didn't say it's limited, jsut that's it's 'finite' (although i'm 
>> not sure it's the correct translation. what i mean is
>> that the number won't grow exponentially with the number of web user), 
>> actually it's stored in an SQL database
>> and queried by the mean of mod_rewrite external map.
>> There is more than one thousand entries,
>>     
>

> OK, so the hash is appropriate then.

>> Still that's not really a problem since i could build some script which 
>> would do the job, but the idea was to get some
>> automatic load-balancing to keep us from manualy doing the job.
>>     
>

> That's a boring way of doing it, let's stay away from this.
>

You read my mind ;)
>

>> Anyway, thanks for the reply, i'll probably tune apache2 the max i could 
>> 'til we either fix this buggy app server or
>> get some dedicated appliance (if one can do the job... but from my 
>> memories the Cisco CSS could pretty much get
>> sticky on anything)
>>     
>

> Warning! Cisco CSS is extremely full of bugs. One of my customers has
> some and complains a lot about them. It's also the one and single product
> from Cisco that I've seen the salesman refuse to sell!

> Their new ACE models look very promising though. But you pay the price!

> I think I can come up with the hashing in a small time. It would
> guarantee that the same value will always be fetched from the same
> server as long as it's up.

>
>

That's kinda weird. I've used the small version (11501) two years ago with no big problems,
in fact it was one of the only thing we didn't have to cary about ...

>> Btw, i have some weird comportement with the haproxy web site index page 
>> on Firefox 2.0.0.9 on win32, the page doesn't load
>> (the news page does, or anything else like the documentations, or 
>> release packages) but there is no error message, the web page
>> just keep being the previous one. This doesn't appear on IE, nor on 
>> firefox/linux for what i can tell
>>     
>

> Hmmm that's somewhat strange. I've put the same page here without the
> javascript introduced by the google ads just in case it's the problem's
> root :

> http://haproxy.1wt.eu/index2.html

> If that solves the problem, I'll have to speed up the removal of the
> ads from those pages. This was an experiment I performed last year
> but it takes as much time to rework the site as it took to build it
> last. So eventhough those ads don't bring anything, as long as they
> don't cost I have no incentive to work on removing them.

> Thanks for the info!
> Willy
>

I'll let you know if that's better. Received on 2007/11/27 10:08

Re: Haproxy & un-usual session tracking