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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" <bburke(a)redhat.com&gt; > Cc: keycloak-dev(a)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) ;)

> 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(a)redhat.com&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Marek Posolda" <mposolda(a)redhat.com&gt; Cc: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Thursday, 4 June, 2015 12:40:42 PM Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication ----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" > <bburke(a)redhat.com&gt;, keycloak-dev(a)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(a)redhat.com&gt; > >> To: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" > >> <bburke(a)redhat.com&gt; > >> Cc: keycloak-dev(a)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. 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. > > 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(a)redhat.com&gt; 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(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)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(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" >> <bburke(a)redhat.com&gt;, keycloak-dev(a)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(a)redhat.com&gt; >>>> To: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" >>>> <bburke(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; 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(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)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(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" >> <bburke(a)redhat.com&gt;, keycloak-dev(a)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(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" >>>> <bburke(a)redhat.com&gt;, keycloak-dev(a)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(a)redhat.com&gt; >>>>>> To: "mike cirioli" <mikecirioli(a)gmail.com&gt;, "Bill Burke" >>>>>> <bburke(a)redhat.com&gt; >>>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; 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(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Marek Posolda" <mposolda(a)redhat.com&gt;, "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "mike cirioli" <mikecirioli(a)gmail.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Thursday, 4 June, 2015 2:40:54 PM Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication On 6/4/2015 8:09 AM, Marek Posolda wrote: >> 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. > Just hitting the login screen causes a replication/distribution for infinispan, db insert for mongo/jpa. There's no way around that because our authentication layer is decoupled from the login protocol (saml, oidc) and we need to store protocol specific metadata for use after authentication is complete.

Another thought is to store AuthenticationSession into a signed/encrypted cookie or a query parameter so you could avoid sticky sessions.

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

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? 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(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev