JMeter Performance test
by Marek Posolda
I've sent PR https://github.com/keycloak/keycloak/pull/490 with first
prototype of Keycloak performance test with JMeter. For now it's using
embedded Undertow (reused KeycloakServer stuff from testsuite) also with
performance-tools, so it's easy to add new users. Most of the stuff is
configurable through System properties, which allows to easily switch
different databases and models without any needed changes in
configuration files (For example PostgreSQL, MySQL, Mongo,
enabled/disabled simple cache etc), which is also good for easy setup of
performance test in Jenkins to have it in CI. Some details in README:
testsuite/performance-web/README.md .
If you like the approach, I can continue and possibly setup CI. For now,
I've tried some testing on my laptop with 10.000 users in database and
each user having 1 realm role (available through scope to tested web
application) and 0 application roles... (I guess having configurable
number of roles, scopes per user might be useful as well and I can
possibly add it? )
Each test is using 50 clients (each client having different username, so
using users like user-0, user-1, user-49 ) and each client doing 50 test
iterations. Each iteration is doing:
- Redirect to KC login screen
- Login into KC
- Exchange code for token
- Refresh token 2 times
- Logout
Some results from test on my laptop:
PostgreSQL with simple cache disabled:
uri count total min
average max
"Login request" 2500 381151 10 152 1168
"Confirm Login request" 2500 1202384 39 480 1505
"Exchange code request" 2500 1162489 28 464 1677
"RefreshToken request" 5000 1992961 22 398 1630
"Logout request" 2500 786237 21 314 1383
PostgreSQL with simple cache enabled:
uri count total min average
max
"Login request" 2500 168819 6 67 857
"Confirm Login request" 2500 412464 18 164 1205
"Exchange code request" 2500 670047 21 268 1121
"RefreshToken request" 5000 997389 10 199 976
"Logout request" 2500 475672 17 190 1328
Mongo model with simple cache disabled:
uri count total min
average max
"Login request" 2500 171976 6 68 1014
"Confirm Login request" 2500 412258 11 164 981
"Exchange code request" 2500 512125 12 204 1144
"RefreshToken request" 5000 923467 11 184 1073
"Logout request" 2500 367173 10 146 1108
Mongo model with simple cache enabled:
uri count total min average
max
"Login request" 2500 135489 5 54 1085
"Confirm Login request" 2500 224540 7 89 1318
"Exchange code request" 2500 343649 9 137 905
"RefreshToken request" 5000 556202 8 111 750
"Logout request" 2500 292986 10 117 1574
Marek
12 years
Hangout this week to talk about cache and model splitting
by Stian Thorgersen
I'd like to have a hangout this week to talk about cache, clustering and splitting of the model. I'd like to do this a.s.a.p. so we can decide on what we're going to do for 1.0.final.
Last week I experimented with splitting the model into 3 parts: config, users and sessions. I've got something close to working at the moment. The basic idea is to create a new hybrid model provider that delegates to 3 different providers:
* Config SPI - realms, apps, clients, roles and scope mappings
* Could quite easily do a json file implementation. However, what about clustering? Could we just reload the whole realm whenever it's changed?
* Not considering clustering, is there even any reason to store config in a database? Dropping support for DBs and Mongo for config would make things significantly simpler.
* Can we load everything into mem on startup? How would that affect clustering?
* Should we add a revision to realms to make it easy to track consistency across servers in a cluster?
* In the long run we could move code from managers into KeycloakSession and HybridModelProvider (and also extract more shared code from the stores themselves)
* Does it make sense to have a read and read/write mode for config. For example admin uses read/write config, while logins and such use the read only config
* We could add a batch mode to the admin console. An admin can perform a number of changes that are kept in a draft version of the config on the server. Once the admin has done all the changes, he can then choose to review the changes through a page in the admin console and click push if he's happy with it. This could be taken further and have some users that are allowed to perform changes, but not push the changes.
* Users SPI
* Stores users, credentials and role mappings
* I expect this is the only one users of Keycloak could want to implement themselves
* What implementations do we provide? DBs, Mongo, LDAP?, Files?. Does it make sense to use PicketLink here (could provide jdbs, files, ldap, etc..)
* Sessions SPI
* Stores sessions (and probably login failures as well)
* In-mem implementation makes sense here. However, what about clustering?
* Do we still want JPA and Mongo implementations?
12 years
Refactoring to KeycloakSession and ProviderSession
by Stian Thorgersen
I've combined KeycloakSession and ProviderSession into KeycloakSession. There's a single implementation of this (DefaultKeycloakSession).
Model implementations now implement ModelProvider instead of KeycloakSession.
12 years
top-level cache strategy
by Bill Burke
Last week I put in a cache that sits on top of our model API. I'm going
to continue with it and *not* use any caching implementation like
Infinispan. Here's what it will look like:
* Provider SPI for cache implementation
* Simple hand made cluster cache for Keycloak as follows:
- Cache is currently loaded on demand
- Cached objects are read-only and are invalidated at end of transaction
if changed.
- ConcurentHashMaps for non-user information.
- LRU cache for UserModel and Credentials. This will be a synchronized
LinkedHashMap.
- Cluster nodes will be defined manually in keycloak-server.json under
the cache scope.
- Simple secure invalidation REST API
- Simple secure ping REST API
- If a remote invalidation or ping fails, then cache will be wiped and
disabled until a ping can be re-established.
I don't think any of this is much work.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
Beta-3 release in SourceForge was broken
by Stian Thorgersen
All,
The files for 1.0-beta-3 I uploaded yesterday to SourceForge was broken (both appliance-dist and war-dist). I've uploaded fixed files now, so if you've already downloaded the release, please download again!
Cheers,
Stian
12 years, 1 month
