Performance test
by Marek Posolda
Hi,
I've added support for JMeter based performance testing into testsuite
and I did some initial performance tests to compare Picketlink based
store with MongoDB store. As underlying DB for Picketlink, I used MySQL.
For now, the testing scenarios I did are those:
1) Test for creating 10 realms. Each test iteration creates one new
realm and adds some applications, roles and requiredCredentials to it
(namely 5 applications, 7 roles, 3 roles per each created application)
Results: average 662 ms for Picketlink, 135 ms for Mongo (NOTE:
Average=average time of one test iteration, which means creating of one
realm)
2) Test for creating 20000 users. This test is using 10 worker threads.
Each worker will create 2000 users in one of the realms created in step
1. Each user is added in separate iteration and also some infos are
added to this user (Password, default roles of realm and attributes like
firstName, lastName, email etc)
Results: average 103 ms for Picketlink, 63 ms for Mongo (NOTE:
Average=average time of one test iteration, which means creating of one
user and his info. Both Picketlink and Mongo have worse and worse times
during test progress as it seems that time could depend on total number
of already existing objects in DB, which is bigger and bigger.
Unfortunately this difference is more visible for Mongo. I believe that
more investigation of performance and adding some DB indexes will help.
I am attaching charts.)
3) Test for reading users. This test is using 10 worker threads. Each
thread will read realm first and then it will read 5 users from this
realm (Also roles and password are read for each user). I used 500
iterations for this test (So 2500 read users for each worker and 25000
read users in total. DB is prepared with 20000 users from test2, so some
users are read twice)
Results: average 4586 ms for Picketlink, 518 ms for Mongo (NOTE:
Average=average time of one test iteration, which means reading of 5
users and their roles + verifying their password. I am attaching charts)
I will try to do more performance tuning and possibly improve times. Let
me know if you have comments or ideas how to improve testing. I will
send PR soon and share my MongoDB based storage implementation and
performance tests.
Marek
13 years
portal identity experiences
by Bill Burke
> We have some. Which aspect are you interested in? Majority of
> deployments are around integrating MSAD - as majority of organizations
> just inherit it as part of Windows Domain.
>
They used portal as an identity broker to MSAD? What did they use MSAD
for? User metadata and credentials? Or was application security
metadata in their too? (roles/role mappings).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
relationship between application and realm
by Bill Burke
I want to bring this up again because I feel strongly about it. Having
"Application" separate from "Realm" or a top-level-menu item, is not a
good thing for many reasons. I'm talking about this idea of only
creating an Application for single apps through the admin UI and setting
up everything based only on the idea of an Application with no knowledge
of what a realm is.
* Realm is core to the implementation.
* Once you want to do SSO, you have to know what a realm is. This idea
of merging/exporting/importing an Application into a Realm seems just
very complex to me. I'm of the strong opinion that its just not a great
idea because SSO (and Single Log Out) is one of our key features.
* You're not creating an application within Keycloak, you're securing an
application. A Realm really pertains to the auth-server. Application
pertains to the
* JBoss, Tomcat, and Jetty, really most Java developers already know
what a Realm is. Even Basic Auth has the concept of a Realm. Realm is
just such a core concept to security.
* Removing the concept of a Realm for a single-app domain, doesn't
really simplify much for the user. All we're really asking the user to
do is specify a name for the realm and configure providers and manage
users at the realm level.
* Having a noticably different UI for a one-off-app vs. a multi-app
realm is just confusing to the user. It creates more work for us, for
very little gain.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
Transaction has been retired
by Bill Burke
* Implemented a Servlet Filter to do this as we discussed before
* Unit tests now use Undertow. See new class AbstractKeycloakServerTest
* All sub resources need to be initialized using a ResourceContext now
* @Context inject KeycloakSession and/or KeycloakTransaction as needed.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
