Fragile caching mechanism #735
Description
Activity
Thanks for bringing this up! Yes, the local caching mechanism should work over a single request lifecycle. I think we can improve this by hooking the cache onto the Split::Helper instead.
The ideal solution would be to solve what's causing the performance impact. The number of Redis calls made per single request. But that needs a lot more work.
We solved the performance issue we were having not by using Split's built in cache but by using a request cache such as rails "CurrentAttributes". Maybe it's worthy to implement/use a request cache instead.
- added a commit that references this issue
on Feb 14, 2026 Thank you for this great gem. We've been using Split with caching enabled for about 3 years to address performance issues. Recently, we discovered problems when setting a winner from the dashboard, which led us to this issue.
This cache invalidation problem is serious and can cause production incidents. I've submitted a PR #743 to add a warning to the README to help prevent others from encountering the same issues.
Thanks, and sorry for that problem.
My plan is to remove the need for this cache at all. #742 removed most of the redis requests that made the performance hit. Still need to do some testing, but after that, I'll release a new version disabling the cache
Reacted by Shinji Nakamatsu and oku3san
Describe the bug
Split caching system isn't thread / process safe. When the request ends, the cache remains set in the process.
This is due to Split using class instance variables to store the cache.
In a scenario in which you're using Puma with multiple processes handling requests, this is not ideal.
If one process removes or resets an experiment, the cache only gets reset in a single process. Not in all the processes having the cached values.
To Reproduce
Using puma, Split with cache enabled, and 2 browser windows:
Suggestions
CurrentAttributesfor the caching mechanism instead of the current class instance variable method.