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

[Marek Posolda]

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.
>
> 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
>>>>
>>