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

[Stian Thorgersen]

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

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