Hi, Moving the discussion to the dev mailing list.
I think that using the userId suffix was made to improve performance when searching for user sessions. Instead of scanning all existing keys to see if it is a TGT of this user, the idea was to scan only the tickets made for this user. About the solutions, I don't think we should remove the userId suffix as we would lose the previous improvement. I think that a new cache would make sense to improve performance but I would store it directly in Redis to make things easier. In fact, we would have a double keys indexing, maybe something like: CAS_TICKET_USER:ticketId:userId => (ticket) + CAS_TICKET:ticketId => (CAS_TICKET_USER:ticketId:userId) @Misagh: what do you think of this problem and solutions? Thanks. Best regards, Jérôme Le ven. 28 oct. 2022 à 14:05, Pascal Rigaux <[email protected]> a écrit : > Solutions I can think of: > > - add a memory cache [ ticketId => redisKey ] > (it should help a lot, even if it will still be slower than before in > case of load balancing) > > - revert suffixing redis key with userid > (easy change in RedisTicketRegistry.java) > > - and possibly add userid suffix in a UniqueTicketIdGenerator, the way > HostNameBasedUniqueTicketIdGenerator suffixes with hostname > (but it may be hard to do...) > > cu > > On 28/10/2022 11:13, Jérôme LELEU wrote: > > Hi, > > > > Thanks for raising the point. > > > > It's always hard to find a good balance between a generic design and > performance. > > > > It seems to me that performing scans to get a ticket is not the best > thing to do in terms of performance. > > > > The Redis ticket registry is commonly used and we should try to avoid > any performance degradation. > > > > I have a few ideas in mind, but I'm not a Redis specialist: what do you > propose? > > > > Thanks. > > Best regards, > > Jérôme > > > > > > Le jeu. 27 oct. 2022 à 19:59, Pascal Rigaux < > [email protected] <mailto:[email protected]>> a > écrit : > > > > Hi, > > > > In 6.6.x Redis ticket registry key is suffixed with userid (since > 6.6.0-RC4) > > > > This is great to know who owns a TGT or a ST. > > > > Alas, this means getting a TGT from Redis now requires a "SCAN"... > which is much more costly. > > Example: full "SCAN" is ~100 times slower then "GET" on our > production Redis (dbsize ~100k, because we have 1 month rememberMe TGT) > > > > > > For the record, getting a ST triggers > > - on 5.3 : 8 redis "GET" on the TGT > > - on 6.5 : 17 redis "GET" on the TGT > > - on 6.6 : 15 redis "SCAN" + "GET" on the TGT on a small redis db > > > > > > > > PS: "cas.ticket.registry.core.enable-locking=false" fails on redis > ticket registry with error > > > Could not find a destroy method named 'destroy' on bean with > name 'casTicketRegistryRedisLockRegistry' > > -- > - Website: https://apereo.github.io/cas > - Gitter Chatroom: https://gitter.im/apereo/cas > - List Guidelines: https://goo.gl/1VRrw7 > - Contributions: https://goo.gl/mh7qDG > --- > You received this message because you are subscribed to the Google Groups > "CAS Community" 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-user/fcfa4754-17f7-384f-7254-e6faad0f4cff%40univ-paris1.fr > . > -- 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/CAP279Lw22-%2Bc4YRBunkfOErebndGrpQrTK39Dixxpa9CmVqTjg%40mail.gmail.com.
