<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:10px">Hi Marek<br id="yui_3_16_0_ym19_1_1465797102861_4190"><br id="yui_3_16_0_ym19_1_1465797102861_4191">I'm working with Fabricio on the federation performance issues with Keycloak.<br id="yui_3_16_0_ym19_1_1465797102861_4192"><br id="yui_3_16_0_ym19_1_1465797102861_4193">In answer to your question we are using the latest KC 1.9.7 version (we upgraded this week from 1.9.2).<br id="yui_3_16_0_ym19_1_1465797102861_4194"><br id="yui_3_16_0_ym19_1_1465797102861_4195">To give you some indication of the running a gatling direct access login test (results below).<br id="yui_3_16_0_ym19_1_1465797102861_4196"><br id="yui_3_16_0_ym19_1_1465797102861_4197">As you can see below in (1) using KC out of the box. Great performance - we saw 110 tx per sec on a 4 core system.<br id="yui_3_16_0_ym19_1_1465797102861_4198"><div id="yui_3_16_0_ym19_1_1465797102861_4449">In scenario (2) using a stubbed federator (simply an echo plugin not connecting to any back end services), performance is unacceptable.</div><br id="yui_3_16_0_ym19_1_1465797102861_4200">1) Not using the federator - Stub federator (disabled) - while 29 tx per second we could easily get to a stable 110 tx per second.<br id="yui_3_16_0_ym19_1_1465797102861_4201"> 300 Users (hitting single server)<br id="yui_3_16_0_ym19_1_1465797102861_4202"> ---- Global Information --------------------------------------------------------<br id="yui_3_16_0_ym19_1_1465797102861_4203"> > request count 9185 (OK=9185 KO=0 )<br id="yui_3_16_0_ym19_1_1465797102861_4204"> > min response time 18 (OK=18 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4205"> > max response time 723 (OK=723 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4206"> > mean response time 27 (OK=27 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4207"> > std deviation 44 (OK=44 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4208"> > response time 50th percentile 20 (OK=20 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4209"> > response time 75th percentile 21 (OK=21 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4210"> > mean requests/sec 29.626 (OK=29.626 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4211"> ---- Response Time Distribution ------------------------------------------------<br id="yui_3_16_0_ym19_1_1465797102861_4212"> > t < 800 ms 9185 (100%)<br id="yui_3_16_0_ym19_1_1465797102861_4213"> > 800 ms < t < 1200 ms 0 ( 0%)<br id="yui_3_16_0_ym19_1_1465797102861_4214"> > t > 1200 ms 0 ( 0%)<br id="yui_3_16_0_ym19_1_1465797102861_4215"> > failed 0 ( 0%)<br id="yui_3_16_0_ym19_1_1465797102861_4216"><br id="yui_3_16_0_ym19_1_1465797102861_4217">2) Stub federator (enabled)- if we brought test down to 12 tx per second (about 90 users) the response times dropped to < 1200 ms response times, however not even close to meeting out acceptance creteria.<br id="yui_3_16_0_ym19_1_1465797102861_4218"> 300 Users (hitting single server) <br id="yui_3_16_0_ym19_1_1465797102861_4219"> ---- Global Information --------------------------------------------------------<br id="yui_3_16_0_ym19_1_1465797102861_4220"> > request count 8496 (OK=8496 KO=0 )<br id="yui_3_16_0_ym19_1_1465797102861_4221"> > min response time 511 (OK=511 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4222"> > max response time 11191 (OK=11191 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4223"> > mean response time 6832 (OK=6832 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4224"> > std deviation 2329 (OK=2329 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4225"> > response time 50th percentile 7194 (OK=7194 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4226"> > response time 75th percentile 8690 (OK=8690 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4227"> > mean requests/sec 27.404 (OK=27.404 KO=- )<br id="yui_3_16_0_ym19_1_1465797102861_4228"> ---- Response Time Distribution ------------------------------------------------<br id="yui_3_16_0_ym19_1_1465797102861_4229"> > t < 800 ms 154 ( 2%)<br id="yui_3_16_0_ym19_1_1465797102861_4230"> > 800 ms < t < 1200 ms 85 ( 1%)<br id="yui_3_16_0_ym19_1_1465797102861_4231"> > t > 1200 ms 8257 ( 97%)<br id="yui_3_16_0_ym19_1_1465797102861_4232"> > failed 0 ( 0%)<br id="yui_3_16_0_ym19_1_1465797102861_4233"><br id="yui_3_16_0_ym19_1_1465797102861_4234">This is currently a show stopper for us and is blocking our path to production.<br id="yui_3_16_0_ym19_1_1465797102861_4235">Do you run similar tests and how can we help you optimise the performance?<br id="yui_3_16_0_ym19_1_1465797102861_4236"><br id="yui_3_16_0_ym19_1_1465797102861_4237">Regards<br id="yui_3_16_0_ym19_1_1465797102861_4238">Tom.<br id="yui_3_16_0_ym19_1_1465797102861_4239"><br id="yui_3_16_0_ym19_1_1465797102861_4240"><br id="yui_3_16_0_ym19_1_1465797102861_4241">Date: Wed, 8 Jun 2016 12:28:19 +0200<br id="yui_3_16_0_ym19_1_1465797102861_4242">From: Marek Posolda <mposolda@redhat.com><br id="yui_3_16_0_ym19_1_1465797102861_4243">Subject: Re: [keycloak-user] Performance issues with Federation<br id="yui_3_16_0_ym19_1_1465797102861_4244"> provider enabled<br id="yui_3_16_0_ym19_1_1465797102861_4245">To: Fabricio Milone <fabricio.milone@shinetech.com>, keycloak-user<br id="yui_3_16_0_ym19_1_1465797102861_4246"> <keycloak-user@lists.jboss.org><br id="yui_3_16_0_ym19_1_1465797102861_4247">Message-ID: <5757F343.1040803@redhat.com><br id="yui_3_16_0_ym19_1_1465797102861_4248">Content-Type: text/plain; charset="windows-1252"<br id="yui_3_16_0_ym19_1_1465797102861_4249"><br id="yui_3_16_0_ym19_1_1465797102861_4250">Hi,<br id="yui_3_16_0_ym19_1_1465797102861_4251"><br id="yui_3_16_0_ym19_1_1465797102861_4252">what's the keycloak version used? Could you try latest keycloak and <br id="yui_3_16_0_ym19_1_1465797102861_4253">check if performance is still the issue?<br id="yui_3_16_0_ym19_1_1465797102861_4254"><br id="yui_3_16_0_ym19_1_1465797102861_4255">Marek<br id="yui_3_16_0_ym19_1_1465797102861_4256"><br id="yui_3_16_0_ym19_1_1465797102861_4257">On 08/06/16 01:30, Fabricio Milone wrote:<br id="yui_3_16_0_ym19_1_1465797102861_4258">> Hi all,<br id="yui_3_16_0_ym19_1_1465797102861_4259">><br id="yui_3_16_0_ym19_1_1465797102861_4260">> I sent this email yesterday with 5 or more attachments, so I think it <br id="yui_3_16_0_ym19_1_1465797102861_4261">> was blocked or something... here I go again :)<br id="yui_3_16_0_ym19_1_1465797102861_4262">><br id="yui_3_16_0_ym19_1_1465797102861_4263">> I've been running load tests on our application during the last few <br id="yui_3_16_0_ym19_1_1465797102861_4264">> weeks, and having some performance issues when my custom federator is <br id="yui_3_16_0_ym19_1_1465797102861_4265">> enabled.<br id="yui_3_16_0_ym19_1_1465797102861_4266">><br id="yui_3_16_0_ym19_1_1465797102861_4267">> The performance issue does not exist when the federator is disabled.<br id="yui_3_16_0_ym19_1_1465797102861_4268">> *Configuration*:<br id="yui_3_16_0_ym19_1_1465797102861_4269">><br id="yui_3_16_0_ym19_1_1465797102861_4270">> I have a cluster of 2 instances of Keycloak, with a standalone DB, <br id="yui_3_16_0_ym19_1_1465797102861_4271">> we've verified the DB isn't an issue when the federator is disabled. <br id="yui_3_16_0_ym19_1_1465797102861_4272">> Both instances have a quad core CPU and they are in the same network. <br id="yui_3_16_0_ym19_1_1465797102861_4273">> We?ve left the memory at 512MB. The test script, database and API that <br id="yui_3_16_0_ym19_1_1465797102861_4274">> connects to the federator are in separate machines.<br id="yui_3_16_0_ym19_1_1465797102861_4275">> *Federator*:<br id="yui_3_16_0_ym19_1_1465797102861_4276">><br id="yui_3_16_0_ym19_1_1465797102861_4277">> We have a simple custom federator that makes calls to a very <br id="yui_3_16_0_ym19_1_1465797102861_4278">> performant api, which has been tested and is ok. Additionally, we've <br id="yui_3_16_0_ym19_1_1465797102861_4279">> tested stubbing the API so the performance is not a problem there. <br id="yui_3_16_0_ym19_1_1465797102861_4280">> This federator is using a jaxb marshaller to create a request, again <br id="yui_3_16_0_ym19_1_1465797102861_4281">> tested in isolation and is performing well.<br id="yui_3_16_0_ym19_1_1465797102861_4282">><br id="yui_3_16_0_ym19_1_1465797102861_4283">> As the federator is doing a lot of calls to the API (3 per login <br id="yui_3_16_0_ym19_1_1465797102861_4284">> request), I've implemented a httpclient that uses a <br id="yui_3_16_0_ym19_1_1465797102861_4285">> PoolingHttpClientConnectionManager with 1000 connections available to <br id="yui_3_16_0_ym19_1_1465797102861_4286">> use, instead of using the standard apache httpclient from http <br id="yui_3_16_0_ym19_1_1465797102861_4287">> components. That hasn't improved a bit the performance of the system.<br id="yui_3_16_0_ym19_1_1465797102861_4288">> *Tests*:<br id="yui_3_16_0_ym19_1_1465797102861_4289">> It is a gatling scala script that could generate around ~300 (or more) <br id="yui_3_16_0_ym19_1_1465797102861_4290">> requests/second to the direct grants login endpoint using random <br id="yui_3_16_0_ym19_1_1465797102861_4291">> usernames from a list (all of them already registered using KC). The <br id="yui_3_16_0_ym19_1_1465797102861_4292">> script is doing a round robin across both instances of Keycloak with <br id="yui_3_16_0_ym19_1_1465797102861_4293">> an even distribution to each KC instance.<br id="yui_3_16_0_ym19_1_1465797102861_4294">> The idea is simulate a load of 300 to 1500 concurrent users trying to <br id="yui_3_16_0_ym19_1_1465797102861_4295">> login into our systems.<br id="yui_3_16_0_ym19_1_1465797102861_4296">> *Problem*:<br id="yui_3_16_0_ym19_1_1465797102861_4297">><br id="yui_3_16_0_ym19_1_1465797102861_4298">> If I run the tests without using a federation I can see a very good <br id="yui_3_16_0_ym19_1_1465797102861_4299">> performance, but when I try to run the tests with the custom <br id="yui_3_16_0_ym19_1_1465797102861_4300">> federation code, the performance drops from ~150 requests/second to 22 <br id="yui_3_16_0_ym19_1_1465797102861_4301">> req/sec using both instances.<br id="yui_3_16_0_ym19_1_1465797102861_4302">> Memory wise, it seems to be ok. I've never seen an error related to <br id="yui_3_16_0_ym19_1_1465797102861_4303">> memory with this configuration, also if you take a look at the <br id="yui_3_16_0_ym19_1_1465797102861_4304">> attached visualVM screenshot you'll see that memory is not a problem <br id="yui_3_16_0_ym19_1_1465797102861_4305">> or it seems not to be.<br id="yui_3_16_0_ym19_1_1465797102861_4306">> CPU utilisation is very low to my mind, I'd expect more than 80% of <br id="yui_3_16_0_ym19_1_1465797102861_4307">> usage or something like that.<br id="yui_3_16_0_ym19_1_1465797102861_4308">> There is a method that is leading the CPU samples on VisualVM called <br id="yui_3_16_0_ym19_1_1465797102861_4309">> Semaphore.tryAcquire(). Not quite sure what's that for, still <br id="yui_3_16_0_ym19_1_1465797102861_4310">> investigating.<br id="yui_3_16_0_ym19_1_1465797102861_4311">><br id="yui_3_16_0_ym19_1_1465797102861_4312">> I can see that a lot of new threads are being created when the test <br id="yui_3_16_0_ym19_1_1465797102861_4313">> starts, as it creates around 60requests/second to the direct grants <br id="yui_3_16_0_ym19_1_1465797102861_4314">> login call, but it seems to be a bottleneck at some point.<br id="yui_3_16_0_ym19_1_1465797102861_4315">><br id="yui_3_16_0_ym19_1_1465797102861_4316">> So I'm wondering if there is some configuration I'm missing on <br id="yui_3_16_0_ym19_1_1465797102861_4317">> Keycloak side that could be affecting the cluster performance when a <br id="yui_3_16_0_ym19_1_1465797102861_4318">> federator is enabled. Maybe something related to jpa connections, <br id="yui_3_16_0_ym19_1_1465797102861_4319">> infinispan configuration or even wildfly.<br id="yui_3_16_0_ym19_1_1465797102861_4320">><br id="yui_3_16_0_ym19_1_1465797102861_4321">> I'd really appreciate your help on this one as I'm out of ideas.<br id="yui_3_16_0_ym19_1_1465797102861_4322">><br id="yui_3_16_0_ym19_1_1465797102861_4323">> I've attached some screenshots of visualVM and tests results from my <br id="yui_3_16_0_ym19_1_1465797102861_4324">> last run today.<br id="yui_3_16_0_ym19_1_1465797102861_4325">><br id="yui_3_16_0_ym19_1_1465797102861_4326">><br id="yui_3_16_0_ym19_1_1465797102861_4327">> Sorry for the long email and please let me know if you need further <br id="yui_3_16_0_ym19_1_1465797102861_4328">> information.<br id="yui_3_16_0_ym19_1_1465797102861_4329">><br id="yui_3_16_0_ym19_1_1465797102861_4330">> Thank you in advance,<br id="yui_3_16_0_ym19_1_1465797102861_4331">><br id="yui_3_16_0_ym19_1_1465797102861_4332">> Regards,<br id="yui_3_16_0_ym19_1_1465797102861_4333">> Fab<br id="yui_3_16_0_ym19_1_1465797102861_4334">><br id="yui_3_16_0_ym19_1_1465797102861_4335">> -- <br id="yui_3_16_0_ym19_1_1465797102861_4336">> *Fabricio Milone*<br id="yui_3_16_0_ym19_1_1465797102861_4337"><div dir="ltr">> Developer</div></div></body></html>