On 4.6.2015 14:18, Stian Thorgersen wrote:
----- Original Message -----
> From: "Marek Posolda" <mposolda(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: "mike cirioli" <mikecirioli(a)gmail.com>, "Bill Burke"
<bburke(a)redhat.com>, 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>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> Cc: "mike cirioli" <mikecirioli(a)gmail.com>, "Bill
Burke"
>>> <bburke(a)redhat.com>, 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>
>>>>> To: "mike cirioli" <mikecirioli(a)gmail.com>,
"Bill Burke"
>>>>> <bburke(a)redhat.com>
>>>>> 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>
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
>>>>>
>