Hi,
I made a new test with 7.0.0-RC2 in a two node environment with round robin.
Indeed, the average time is 0 ms. Performances are excellent!
Thanks.
Best regards,
Jérôme
Le ven. 18 nov. 2022 à 18:54, Misagh a écrit :
> very nice!
>
> Could I ask you to also verify master (or v7 RC2) with a
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 wrote:
>
> Hi,
>
> Some
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
EXCELLENT!
Le mar. 15 nov. 2022 à 04:54, Misagh a écrit :
>
>
>
> On Mon, Nov 14, 2022, 4:58 PM Jérôme LELEU 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
On Mon, Nov 14, 2022, 4:58 PM Jérôme LELEU 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
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 have launched my previous scenario again (10 000 logins).
CAS v6.5: Average time: 2 ms
CAS v7.0.0 fix
Sure. I will test that on Monday (tomorrow is off in France :-)
Le jeu. 10 nov. 2022 à 17:27, Misagh a écrit :
> Could I ask you to review and test this?
> https://github.com/mmoayyed/cas/compare/master...mmoayyed:cas:redis-fix
>
> On Thu, Nov 10, 2022 at 1:03 PM Misagh wrote:
> >
> > Thank
Could I ask you to review and test this?
https://github.com/mmoayyed/cas/compare/master...mmoayyed:cas:redis-fix
On Thu, Nov 10, 2022 at 1:03 PM Misagh wrote:
>
> Thank you Jérôme. I'll take a look.
>
> -- Misagh
>
> On Wed, Nov 9, 2022, 2:39 PM Jérôme LELEU wrote:
>>
>> Hi,
>>
>> I have made a
Thank you Jérôme. I'll take a look.
-- Misagh
On Wed, Nov 9, 2022, 2:39 PM Jérôme LELEU wrote:
> Hi,
>
> I have made a Redis performance test between v6.5.9 and v7.0.0-RC1 and
> figures are very relevant.
>
> In both cases, I have a CAS server using a Redis ticket registry (Docker
> image) and
Hi,
I have made a Redis performance test between v6.5.9 and v7.0.0-RC1 and
figures are very relevant.
In both cases, I have a CAS server using a Redis ticket registry (Docker
image) and a custom authentication handler to validate any username
starting with "jleleu".
I have a script which
Hi,
Yes, double indexing is harder than simple indexing as the second operation
may fail and you should revert the first one (transactional aspect).
If we did that for all tickets, we would double the size of the keys, but
not the size of the database though.
And maybe we should have two
> 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:
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
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
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
15 matches
Mail list logo
