I will take a second look to see if this can be improved, though I am intrigued by your "double key indexing" solution. Do you think you could put together some sort of POC to demonstrate this idea? The other solutions are non-starters. I'll also poke around to see what can be done to speed things up.
On Fri, Oct 28, 2022 at 4:30 PM Jérôme LELEU <[email protected]> wrote: > > 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. -- 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/CAGSBKkfEV2jEH%2BeRoWjnHPO71m1e4QFqRjL5H_iCJz2tyg7n5g%40mail.gmail.com.
