Sent invite for Monday in Zimbra (15pm GMT). If that's not suitable let me know.
A few more areas to look at:
* Profile to find crappy code
* Tune FreeMarker and themes
* Sharding / sticky sessions - this is probably for later, but I'd like to discuss it
in the hangout
A few comments on database caching:
* We may need to do this in stages
- 2nd level cache for beta-2?
- Something more advanced in after 1.0.final
* I'd don't like the idea of us re-inventing the wheel
- Caching has a lot of complex considerations (node discovery, fail-over, node
recovery, invalidation, lan/wan, jta, etc.)
* I really like the idea of having a cache model provider that delegates to another model
for persistence / this is definitively the way to go IMO
* User sessions needs to separate considerations, specifically I think we can come up with
something clever to minimise the writes required
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 29 May, 2014 8:12:03 PM
Subject: [keycloak-dev] Next step performance
I'd like to have a hangout next week on this. There's really 4 areas to
focus on:
1. Set up a good performance test and get a baseline on current code.
2. Database caching. There are multiple approaches.
* Our caches will be read-mostly except for user session management.
* Write our own REST cache. My idea was to implement a new model
provider that delegates to the real underlying model provider. It would
send RESTful invalidation messages secured by keycloak in a clustered
environment. Maybe use Infinispan or some other local-only cache as the
backbone. I'm really really wary of using Infinispan (or other cache's)
clustering options. I'm not sure how well these guys work in cloud
clustered environments. And I'm not sure how well they've thought of
security.
* Use Hibernate 2nd level cache. Really wary of this as I don't know
how well Infinispan et. al. work in a cloud environment. I'd really
like something HTTP based and authenticated by Keycloak. I'm not sure
we'll be able to get the level of control here either that we need.
* Another reason for a custom cache, is, IMO, almost everything can be
stored in memory. Even users.
3. Clustering.
* Keycloak is not completely stateless. Specifically access codes are
stored in memory. We should be able to move this state information into
a cookie.
* User Session management is a huge issue as it is the only thing that
is write-mostly.
4. HTTP Cache-Control
* All themed static content should support a way to set up cache-control
headers.
* Admin REST api could do cache-control too if we had a way to determine
a version number or timestamp on model data. Not that important though
as, IMO, admin rest api isn't going to have a lot of volume.
--
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