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

Thu Jun 4 08:29:48 EDT 2015


----- 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:26:36 PM
> Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication
> 
> 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.

Clever me :)

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