Hi, Some follow up on this master. I have made new performance tests between v6.6.2 and v6.6.3-SNAPSHOT to evaluate the backport from v7.
For 5000 logins and service ticket validations: 6.6.2 : Average time: 221 ms 6.6.3-SNAPSHOT: Average time: 4 ms Performance are now very good for the incoming 6.6.3 release. Thanks. Best regards, Jérôme Le mardi 15 novembre 2022 à 07:48:36 UTC+1, leleuj a écrit : > EXCELLENT! > > Le mar. 15 nov. 2022 à 04:54, Misagh <[email protected]> a écrit : > >> >> >> >> On Mon, Nov 14, 2022, 4:58 PM Jérôme LELEU <[email protected]> wrote: >> >>> Hi, >>> >>> I have made new tests. >>> >>> With the new implementation, I have experienced Redis crashes, but I'm >>> not sure this is meaningful. >>> In any case, I have updated to Redis v7 with 500Mo of memory. >>> >> >> I ran into something similar. I think this is mainly due to the large >> number of operations and tickets and that the redis setup is not exactly >> tuned to handle the load. >> >> >>> >>> CAS v6.5 : >>> Average time node 1: 1 ms >>> Average time node 2: 1 ms >>> >>> CAS v7.0.0 fix REDIS : >>> Average time node 1: 2 ms >>> Average time node 2: 2 ms >>> >>> While it performs better on CAS v6.5, it now performs very well on CAS >>> v7 as well. >>> >>> Did you change something else in addition to the cache? >>> >> >> Yes I am experimenting with the ticket pattern lookup to not use >> scanning. This seems to be good enough even without the cache. If you >> disable the cache altogether on a single node by forcing its capacity to be >> at 0, (i.e never cache anything) you should see comparable performance >> numbers. This should fit the scope of 6.6, if we were to backport. >> >> I'd like to keep the cache changes in master and continue testing. Cache >> invalidation can be very tricky here to make sure updates and changes to >> one ticket on one node is correctly found and processed on another. Given >> the current caching model is incredibly fast, I'd like to stick to this >> strategy and work out the other possible issues with clustered setups and >> event sinks. If I cannot make it work reliably, then I would consider >> either removing the cache or changing its structure. It would be slower >> than what it is now, but still very very fast. >> >> And if this technique works ok, it might be something to extend to other >> registry plugins as the need comes up. >> >> >> >> >>>>> -- >> You received this message because you are subscribed to the Google Groups >> "CAS Developer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfu1sjXEO1MPiq%3DjhhNhce%3DX6gy_LwASdvuMeRtUZ5hfQ%40mail.gmail.com >> >> <https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAGSBKkfu1sjXEO1MPiq%3DjhhNhce%3DX6gy_LwASdvuMeRtUZ5hfQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "CAS Developer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-dev/85ebafde-394c-4cf3-b542-066810bfcc74n%40apereo.org.
