The project historically uses the jwt_sessions gem.
When the number of online users reaches a certain point, around N keys are created in Redis, and performance issues start to appear, primarily due to the Redis SCAN function, according to our Datadog monitors.
The execution time of the SCAN function in Redis depends on the total number of keys in the database. As the number of keys grows, the operation’s duration increases, since the complexity of SCAN is asymptotically linear with respect to the number of keys that need to be scanned.
In other words, even upgrading to a more powerful Redis instance won’t solve the problem — the SCAN function is inherently expensive, and the issue will only worsen as the number of online clients grows.
Do you have any ideas on how to get rid of such an expensive function as loop + scan? (lines 154-165)
And one more question: have you conducted any stress tests for the jwt_sessions gem? If there are results from these tests, could you share them or add them to the README.md?
The project historically uses the
jwt_sessionsgem.When the number of online users reaches a certain point, around N keys are created in Redis, and performance issues start to appear, primarily due to the Redis SCAN function, according to our Datadog monitors.
The execution time of the SCAN function in Redis depends on the total number of keys in the database. As the number of keys grows, the operation’s duration increases, since the complexity of SCAN is asymptotically linear with respect to the number of keys that need to be scanned.
In other words, even upgrading to a more powerful Redis instance won’t solve the problem — the SCAN function is inherently expensive, and the issue will only worsen as the number of online clients grows.
Do you have any ideas on how to get rid of such an expensive function as loop + scan? (lines 154-165)
And one more question: have you conducted any stress tests for the
jwt_sessionsgem? If there are results from these tests, could you share them or add them to the README.md?