Redis Memory over usage on CAS 7

[Prakash Thapa]

Since I upgraded to CAS 7, I am experiencing frequent 100% usage in my Redis Memory. I had upgraded from CAS 5. I am not sure if newer version of CAS stores additional information to Redis beside of tickets or if I am missing any configuration.

It would be very much helpful if anyone familiar with this share their experiences.

[Jérôme LELEU]

Hi,

In v7, the Redis support consumes more memory and more bandwidth due to the fact that tickets are now JSON documents instead of serialized binary.

You may need to resize your Redis memory to take that into account.

Thanks.

Best regards,

Jérôme

Le lun. 23 mars 2026 à 15:07, Prakash Thapa <thapaprak...@gmail.com> a écrit :

Since I upgraded to CAS 7, I am experiencing frequent 100% usage in my Redis Memory. I had upgraded from CAS 5. I am not sure if newer version of CAS stores additional information to Redis beside of tickets or if I am missing any configuration.

It would be very much helpful if anyone familiar with this share their experiences.

--
- Website: https://apereo.github.io/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+u...@apereo.org.
To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/7f1fa7f4-8be7-4576-a6ba-16dcd8c56d43n%40apereo.org.

[Jérôme LELEU]

Hi,

You need to investigate what you have in your Redis system: what kind of tickets do you have? How many TGTs? ST? AT? ... And the size of these tickets? Are some of them really big?

Thanks.

Best regards,

Jérôme

Le ven. 27 mars 2026 à 13:09, Prakash Thapa <thapaprak...@gmail.com> a écrit :

Hi Jérôme,

We upgraded the Redis server and the instance types and size as well. But. we are frequently getting high Redis Memory, Instance CPU and Instance memory utiliization issues after upgrading to CAS 7. 

[Prakash Thapa]

Hi Jérôme,

We upgraded the Redis server and the instance types and size as well. But. we are frequently getting high Redis Memory, Instance CPU and Instance memory utiliization issues after upgrading to CAS 7. 

On Monday, March 23, 2026 at 8:19:27 PM UTC+5:45 Jérôme LELEU wrote:

[Jérôme LELEU]

Hi,

It's important to check the number of tickets by kind: if you have many TGTs, that's not surprising, but you should not have many STs, 0 would be expected.

I once had a customer who had enabled refresh tokens and had polluted its cache with them. So it's important to know what you have in store.

Then it's a matter of size: indeed, many things are stored in the tickets and all this information is generally useful, but sometimes, you may remove information you don't need, like not tracking the descendant tickets or only keeping the latest access for the same service. These are configuration options you may disable/enable.

Thanks.

Best regards,

Jérôme

Le ven. 27 mars 2026 à 15:39, Prakash Thapa <thapaprak...@gmail.com> a écrit :

Additionally, if I customized the default CAS behaviour to only store the tickets and removed the authentication attributes values while saving to Redis, will it break anything in the credential/SAML login or in Single Sign On.

[Prakash Thapa]

I have all kinds of ticket. TGT, PGT, ST and PT (ST and PT are being removed as expected). I noticed that the whole user session and authentication attributes(metadata populated from SuccessfulAuthenticationHandler) are stored in Redis. Is this the expected behaviour? I am testing parallely in a number of services with a number of users. Since the number of ticket generated in large, the data stored in Redis seems to be huge as all the authentication attributes is saved in redis.

[Prakash Thapa]

Additionally, if I customized the default CAS behaviour to only store the tickets and removed the authentication attributes values while saving to Redis, will it break anything in the credential/SAML login or in Single Sign On.

On Friday, March 27, 2026 at 6:22:11 PM UTC+5:45 Prakash Thapa wrote: