[keycloak-user] Keycloak OAuth High CPU usage

[Bill Burke]

Are you benching this with the same user?  Or are there 10-20 different 
users executing at the same time?  I ask because if they are different 
you have to factor in database access.  I think the default connection 
pool size for the DB is 20 connections.

Other things that could factor in:  what are you password hashing 
iterations (its a password policy).  Default is 1, but I don't know if 
you've bumped that to the recommended amount (20,000) which would 
greatly slow things down too.


On 5/19/16 7:24 AM, Vaibhav Naldurgkar wrote:
>
> Hi All,
>
> I am using Keycloak 1.9.3 with default configuration. Keycloak server 
> is installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java 
> version is jdk1.8.0_73 We are trying to use keycloak as a OAuth 
> provider. But when we try and generate 
> token(http:///auth/realms/master/protocol/openid-connect/token) for 
> more than 10-20 users the server gets too slow and cpu usage goes over 
> 100%.
>
> Any pointers on how to improve performance of keycloak OAuth provider. 
> We need to support at least 200 concurrent users.
>
> Thanks, Vaibhav
>
> DISCLAIMER ========== This e-mail may contain privileged and 
> confidential information which is the property of Persistent Systems 
> Ltd. It is intended only for the use of the individual or entity to 
> which it is addressed. If you are not the intended recipient, you are 
> not authorized to read, retain, copy, print, distribute or use this 
> message. If you have received this communication in error, please 
> notify the sender and delete all copies of this message. Persistent 
> Systems Ltd. does not accept any liability for virus infected mails.
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/01600e22/attachment.html