[keycloak-dev] sticky sessions, clustering, and authentication

[Marek Posolda]

On 4.6.2015 14:18, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "mike cirioli" <mikecirioli at gmail.com>, "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Thursday, 4 June, 2015 2:09:10 PM
>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication
>>
>> On 4.6.2015 12:40, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "mike cirioli" <mikecirioli at gmail.com>, "Bill Burke"
>>>> <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 4 June, 2015 10:28:15 AM
>>>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and
>>>> authentication
>>>>
>>>> On 4.6.2015 08:53, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>>>> To: "mike cirioli" <mikecirioli at gmail.com>, "Bill Burke"
>>>>>> <bburke at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, 4 June, 2015 8:49:03 AM
>>>>>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and
>>>>>> authentication
>>>>>>
>>>>>> Question is if the requirement for sticky sessions is not too
>>>>>> restrictive? I guess not everyone want to use sticky sessions.
>>>>>>
>>>>>> Maybe we should offer both possibilities (in-memory + sticky sessions OR
>>>>>> AuthenticationSession saved in infinispan and replicated after each
>>>>>> request) ?
>>>>>>
>>>>>> Another question is if overhead of current replication is really so bad
>>>>>> to introduce another abstraction and increase code complexity?
>>>>> We're not using a replicated cache - we're using a distributed cache.
>>>>>
>>>>> If anyone is worried about performance Google how Google works (hint:
>>>>> sharding) ;)
>>>> yeah, the performance is the question and at some point I want to look
>>>> at it a bit more. For the distributed I am a bit worried if it doesn't
>>>> require more network calls then replicated in some envs. I wonder about
>>>> the situation like:
>>>>
>>>> 1) You open login screen and you're forwarded by LB to node1 where is
>>>> ClientSession created and saved into cache
>>>> 2) You confirm login screen but then you're forwarded by LB to node2.
>>>> Then call to "keycloakSession.sessions().getClientSession()" always
>>>> perform network call to node1 as my ClientSession is saved on node1. Or
>>>> am I wrong here?
>>>>
>>>> So in shortcut, in distribution there is no any overhead with
>>>> replicating the session as it's saved always in one node, but there may
>>>> be much more overhead in lookup for sessions, which are saved on
>>>> different cluster node (unless I am wrong...)
>>> Sticky sessions are horrible and hard to get to work for Keycloak
>>> especially as we have two separate calls (browser and app).
>>>
>>> Only solution without sticky sessions are distributed caches (shards). If
>>> Google can make it scale to their level it shouldn't be a problem for us
>>> either.
>> I didn't mean sticky sessions here, but UserSessions/ClientSessions.
>> Just trying to compare the performance of replication vs. distribution.
>> For large clusters (5+ nodes) distribution is only choice for sure,
>> replicating each item to 5 nodes doesn't scale...
>>
>> However for smaller clusters like 2 nodes, the replication may be better
>> choice than distribution though. With distribution, if you really have
>> network call per "session.sessions().getClientSession()" you may end
>> with 10 network calls per request or so.
> Pretty sure it's the same. Every update to client-session is a message to update. We just need to make sure there's only 1 request to read and 1 to update.
For writes, you did transaction wrapper in Infinispan session provider 
to write just one per request or so. For reads, we don't have anything 
like it.

But I agree, we need some benchmarking first... Without it, it is just 
speculation...

Marek
>
>>> What we do maybe need to optimize is how many calls there are. For example
>>> atm I think we call once to get client session and another for user
>>> session.
>> +1, maybe we can try to see if ClientSession/UserSession can be saved in
>> KeycloakContext.
>>
>> Marek
>>
>>>> Marek
>>>>
>>>>>> Marek
>>>>>>
>>>>>> On 4.6.2015 01:49, mike cirioli wrote:
>>>>>>> So sticky sessions would be needed only during the authentication
>>>>>>> phase,
>>>>>>> and once complete an underlying clustered session would be created?
>>>>>>>
>>>>>>> On Jun 3, 2015 7:00 PM, Bill Burke <bburke at redhat.com> wrote:
>>>>>>>> I was thinking a bit about performance in a cluster.  Right now a
>>>>>>>> client
>>>>>>>> session is created whenever login is initiated.  This ends up
>>>>>>>> requiring
>>>>>>>> the client session to be propagated to the cluster, either through a
>>>>>>>> database insert/update or an infinispan replication.  Then, with each
>>>>>>>> authentication/required action step, another
>>>>>>>> insert/update/replication.
>>>>>>>>
>>>>>>>> I was thinking we should have an AuthenticationSession that was in
>>>>>>>> memory only.  Then, once all authentication and required actions are
>>>>>>>> finished, then create the usersession and client session.  This would
>>>>>>>> require sticky sessions though with a load balancer.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bill Burke
>>>>>>>> JBoss, a division of Red Hat
>>>>>>>> http://bill.burkecentral.com
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>