Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Pound is infront of HAProxy for SSL off-load so HAProxy receives plaint text HTTP requests. I have HAProxy (v1.4.8) infront of two web-app servers hosting the same application. Below is my HAProxy config.

Currently, a client hits HAProxy, and can go to any server for their initial "GET /" request for the root of the site. For example, a client hits ServerA, from that point on they may always get served by ServerA or ServerB, which ever, the session will be sticky to either A or B. Also the reverse happens; a clients initial request may come into ServerB, after this initial request they will always be served by ServerB or ServerA. The session sticks, but sometimes there is this change after the initial request, to the opposing server for all future requests.

Below is my HAProxy config. Have I written this up incorrectly?

listen  app-servers 127.0.0.1:80
    cookie ASP.NET_SessionId prefix
    balance url_param ASP.NET_SessionId
    balance roundrobin 
    option persist
    option redispatch

    # Balance based on ASP .NET sesssion ID
    appsession ASP.NET_SessionId len 64 timeout 30m request-learn prefix

    # Active WebApp servers
    server  appserver1 10.0.0.1:80
    server  appserver2 10.0.0.2:80

Thank you.

share|improve this question

2 Answers 2

if your app is sensitive to users switching app servers while in a session, then you want the sticky hold time set to at least as long as the expiration time of the session cookie.

your sticky table is set to expire entries after 30 minutes. so while your users may continue to send the same session id, if they pause for more than 30 minutes then their connection will be rebalanced. if you don't like this behavior, a setting of 4hr or more is probably appropriate for you. as i said above in bold, at a minimum you want the sticky hold time set to at least as long as the expiration time of the session cookie.

when you use the cookie server insert option, you're adding a cooking with no expiration time. and that cookie says which server to use. since there is no expiration, the client will never be moved to another server.

but you also need to ask yourself why you care. does switching to another server have a huge impact on the user's experience? if so, maybe you should consider this a flaw in your web app and address it at that layer. i could be wrong, but it's somethign to think about.

share|improve this answer
    
Thanks for the great info! Tbh, there is no problem with users switching app servers its more that when it comes to log analysing, their use of the app is all in one log, on the one app server they used. Also, its for some other performance measurement stuff. The web app it's self works without sticky sessions of any sort. BUt we want users to stay on one server to measure load and other factors more easily. Thank you though for some great insight! –  jwbensley Oct 19 '12 at 12:08
up vote 0 down vote accepted

I'm not super happy about this but it realiable works; I have inserted a cookie in to the client requests instead of tracking the ASP .NET session ID:

listen  app-servers 127.0.0.1:80

    cookie server insert
    balance roundrobin 
    option persist
    option redispatch
    server  appserver1 10.0.0.1:80 cookie srv1
    server  appserver2 10.0.0.2:80 cookie srv2
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.