very nice! Could I ask you to also verify master (or v7 RC2) with a clustered setup, whenever you find the chance? I was able to make the cache work across the cluster, and I think you should see the average time be closer to 0.
On Fri, Nov 18, 2022 at 9:33 PM leleuj <[email protected]> wrote: > > 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. -- 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/CAGSBKkcJaC1QaBq%3DhcBqDWRYamUrfM_VGRrxerXompCKMAZNfA%40mail.gmail.com.
