[keycloak-dev] Next step performance

[Stian Thorgersen]

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 at redhat.com>
> To: keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>