Thanks, for pointing me to the replacement sequence, however I still seem
to miss an element.
Whenever I put in my backend
stick-table type string len 52 size 2m expire 3h
stick on req.cook(JSESSIONID)
stick store-response res.cook(JSESSIONID)
I have session stickyness as long as nbproc is 1. Whenever I increase this,
I get a warning on "stick on" that this does not work correctly in multi
process mode. Also the documentation says this. What would be the correct
way to achieve this with nbproc > 1?
Thanks in advance,
Peter
On Fri, Jun 9, 2017 at 12:55 PM, Aleksandar Lazic <al-hapr...@none.at>
wrote:
> Hi Peter Kenens,
>
> Peter Kenens wrote on 09.06.2017:
>
>
> Hi all,
>
> In our setup, we are doing ssl termination at HAProxy. Session stickyness
> is also needed based on JSESSIONID cookie.
>
> Currently, we achieved this by using appsession JESSIONID and we use
> currently HAProxy 1.5.
> Yes ;-)
>
>
> With high volume of data/users, the CPU of that single core goes to 100%.
>
> I understand that more than 1 HAProxy process can be configured (nbproc)
> and via cpu-map and bind-process you can specify to which cores these
> processes might bind.
>
> I also understand that the table with cookies is kept in memory and memory
> cannot be shared between the different processes.
>
> Is there a way how can we scale this to more cores while still having
> session stickyness?
> This is not possible with appsession due to the fact which you have
> mentioned, in memory.
>
> Well I have tried to create a replacement sequence for the appsession.
> https://www.mail-archive.com/haproxy@formilux.org/msg18181.html
>
>
> Please can you try it and tell us what's missing, thanks.
>
> The whole thread starts with this mail.
> https://www.mail-archive.com/haproxy@formilux.org/msg20421.html
>
> I think with peers are you able to handle also multi process haproxy
> stickyness ;-)
>
>
> Thanks in advance,
> Peter
>
>
>
> *-- Best Regards Aleks*
>
