Hi,
I think we were very good on 6.5.x. Only GET for common operations.
Our main problem was the full SCAN of tickets to check if a ticket is a TGT
and if the principal is the right one ("count/get SSO sessions").
For this one, I would have created a "double key indexing", big words for a
simple thing ;-)
On 6.5.x, we stored tickets this way: key=CAS_TICKET:ticketId =>
VALUE=serialized ticket
I propose for the "add ticket" operation to check if it is a TGT: in that
case, I would add to Redis: key=CAS_TICKET_USER:ticketId:userId =>
VALUE=nothing.
This way, we would "only" SCAN keys of TGT sessions to find the right user
(CAS_TICKET_USER:*:userId) and we would retrieve all the TGT identifiers
for a given user.
Then, a multi GET on these identifiers would find the SSO sessions of the
user.
The new key should be updated and deleted when the related TGT is updated
or deleted.
Thanks.
Best regards,
Jérôme
Le ven. 4 nov. 2022 à 18:57, Misagh <misagh.moay...@gmail.com> a écrit :
> 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 <lel...@gmail.com> 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 <
> pascal.rig...@univ-paris1.fr> 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 <
> pascal.rig...@univ-paris1.fr <mailto:pascal.rig...@univ-paris1.fr>> 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 cas-user+unsubscr...@apereo.org.
> >> 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 cas-dev+unsubscr...@apereo.org.
> > 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 cas-dev+unsubscr...@apereo.org.
> 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
> .
>
--
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 cas-dev+unsubscr...@apereo.org.
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-dev/CAP279LxLCL0VSO5xBxPqzmh7jYbw0jTjC7n5r6iMJTqp3YxgFQ%40mail.gmail.com.
