<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/03/16 16:34, Bill Burke wrote:<br>
</div>
<blockquote cite="mid:56D9AAEC.1030500@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
There's a minimum of 4 Http Requests. There is about 6 SQL
queries to load a user. So, if there is 2 nodes, you have minimum
12 queries for an uncached user. It really all depends how big the
cache can be. Couldn't a million users be cached on a pretty
inexpensive box? My laptop has 32 gig ram. 10K per user is 10
gigs for a million users.<br>
<br>
Then, depending on UserSession ownership setting, you have
pulling/grabbing/replication of the client sessions as you hop
between nodes. This is the one that can't be fixed. I don't know
how much of a big deal it is.<br>
</blockquote>
Just one important thing about how distributed infinispan caches
work by default. I think it's quite important and may not be
obvious, so writing it here just for case. Feel free to ignore if
you're already aware of it.<br>
<br>
If you have numOwners=1 in configuration and on node1 you call:<br>
<br>
cache.put("session-id1", userSession1);<br>
<br>
It doesn't mean that session is automatically saved on the local
node (node1 in this case). Session can be saved internally on node2
and when you call on node1:<br>
<br>
cache.get("session-id1");<br>
<br>
you may always have some remote cluster calls to lookup session from
node2.<br>
<br>
It seems by default infinispan decides just based on the hash of key
(sessionId in our case). Hopefully it's possible to change this
behaviour by use some custom hash factory :
<a class="moz-txt-link-freetext" href="http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hashing_algorithms">http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hashing_algorithms</a>
. IMO we should first investigate this, otherwise we may end with
situation when we implement sticky sessions support, but there won't
be any performance gain regarding userSessions lookup because of
this infinispan behaviour.<br>
<br>
Marek<br>
<blockquote cite="mid:56D9AAEC.1030500@redhat.com" type="cite"> <br>
<div class="moz-cite-prefix">On 3/4/2016 10:18 AM, Stian
Thorgersen wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAfgChGieWZ8bOcMiV5zdtPyvsFb3XAazAKkY-WhFY0Ksw@mail.gmail.com"
type="cite">
<div dir="ltr">Users are cached so that helps + it's possible to
load balance based on source address. Do you really think that
a lot of people will run that many nodes in either case?</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 4 March 2016 at 14:52, Bill Burke
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> I"m not sure how
well keycloak would scale without this.
<div>
<div class="h5"><br>
<br>
<div>On 3/4/2016 7:15 AM, Stian Thorgersen wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr">Eventually it would be nice to
support the ability for load balancers to send
all requests for a particular user session to
the same node (browser as well as client
requests).
<div><br>
</div>
<div>More details here: <a
moz-do-not-send="true"
href="https://issues.jboss.org/browse/KEYCLOAK-2352"
target="_blank"><a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/KEYCLOAK-2352">https://issues.jboss.org/browse/KEYCLOAK-2352</a></a></div>
<div><br>
</div>
<div>Is this a high priority for 1.9 or should
it be 2.x? We may be able to put it into 1.9.2
if required.</div>
<div><br>
</div>
<div>I'd like feedback on how useful folks think
it would be as well as feedback on the
proposed implementation.</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
keycloak-user mailing list
<a moz-do-not-send="true" href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
<span class="HOEnZb"><font color="#888888"> </font></span></blockquote>
<span class="HOEnZb"><font color="#888888"> <br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a moz-do-not-send="true" href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</font></span></div>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://bill.burkecentral.com">http://bill.burkecentral.com</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</body>
</html>