Re: Strange session affinity behaviour

Le mercredi 8 décembre 2010 21:37:31, Tim Perrett a écrit : > Thanks very much for the reply. Interesting about nbproc - its in > nearly every example online.

Despite Willy often asks to remove nbproc to solve many problems :-)

> Moreover, what are the guidelines for
> using appsession vs cookie? Would be good to understand this a little
> more.

"cookie" is somewhat the standard : it doesn't require memory. HAProxy only has to parse the request to know on which server to send it.

"appsession" is mainly there for cases where cookies are not supported by the client. The drawbacks :
- can't work correctly with multiple processes for your frontend (to simplify, mainly with "nbproc > 1").
- the more sessions you have, the more memory you use. - doesn't like haproxy reloads/restarts (session hash is cleared).

As a third persistance solution, you've also got the "stick tables" introduced in HAProxy 1.4.

> In my testing earlier, I added "request-learn" to the end of > appsession and that fixed it, why is that?

Because request-learn sometimes can help to repair the session hash. It depends on the balancing algorithm used : it looks like you were alone on the servers during your tests so it's easier to repair with your round robin algorithm. With several concurrent users it can't always work.

To analyze your logs :
* Without request-learn :
### Request 1 ###
Process : 1
Client cookie : none
Server used (round robin) : SERVER 1
Server cookie : JSESSIONID=HZEEB54EBF02B24933A0825

=> SERVER 1 creates the session HZEEB54EBF02B24933A0825
=> PROCESS 1 associates HZEEB54EBF02B24933A0825 to SERVER 1

### Request 2 ###
Process : 2
Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server used (round robin) : SERVER 1
Server cookie : none

=> PROCESS 2 doesn't know HZEEB54EBF02B24933A0825 but hopefully load balance
to SERVER 1 which knows the session

### Request 3 ###
Process : 1
Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server retrieved (session hash entry) : SERVER 1 Server cookie : -

=> PROCESS 1 knows that HZEEB54EBF02B24933A0825 is for SERVER 1

### Request 4 ###
Process : 2
Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server used (round robin) : SERVER 2
Server cookie : JSESSIONID=HZ4ECA6F75E7FE4D1C980EA

=> PROCESS 2 still doesn't know HZEEB54EBF02B24933A0825 and sadly load balance
to SERVER 2 (round robin in action)
=> SERVER 2 creates the session HZ4ECA6F75E7FE4D1C980EA
=> PROCESS 2 associates HZ4ECA6F75E7FE4D1C980EA to SERVER 2

• With request-learn : ### Request 1 ### Process : 1 Client cookie : none Server used (round robin) : SERVER 1 Server cookie : JSESSIONID=HZEEB54EBF02B24933A0825

=> SERVER 1 creates the session HZEEB54EBF02B24933A0825
=> PROCESS 1 associates HZEEB54EBF02B24933A0825 to SERVER 1

### Request 2 ###
Process : 2
Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server used (round robin) : SERVER 1
Server cookie : none

=> PROCESS 2 doesn't know HZEEB54EBF02B24933A0825 but hopefully load balance
to SERVER 1 which knows the session
=> request-learn repairs the session hash : HZEEB54EBF02B24933A0825 is
associated to SERVER 1

### Request 3 ###
Process : 1
Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server retrieved (session hash entry) : SERVER 1 Server cookie : none

=> PROCESS 1 knows that HZEEB54EBF02B24933A0825 is for SERVER 1

Next request will be OK because request-learn previously repaired the session hash and could be like this :
### Request 4 ###
Process : 2
Client cookie : JSESSIONID=HZEEB54EBF02B24933A0825 Server retrieved (session hash entry) : SERVER 1 Server cookie : none

-- 
Cyril Bonté