Shutdown cache

[sgeef]

Hi,

We are encountering an issue that some requests are hanging or even timing out, and our thought is that it has to do with our high load and the device_detector library as it always happens before our first db call which only has the device detection before it. and then specifically caused by the Mutex locking.

Our servers are running with puma and concurrency. but more important, none of the user agents in the time frame of 5000 cached keys is expected to be equal or very little ones.

Is setting the cache amount to 0 enough? or will this break the caching option?

what do you suggest/think?

Kind regards,
Stephan

[matisojka]

Hello Stephan

Sorry for the late reply. I will have a look into this and get back to you soon.

[matisojka]

Now that I think about the caching topic, in retrospect, it looks like a bad idea to have an in-memory, mutex-locked specific cache implementation in the gem itself. I actually prefer simplicity, and the UNIX philosophy of laser sharp and focused tools that do one thing, but they do it great.

Right now, there is no way to disable the cache entirely. This is something that I will work on to change next. I'll try to keep the current interface, but will remove the cache entirely and leave it up to the library consumer to decide how to cache the results.

[matisojka]

I have pushed a new version to master, that only caches certain regexes without a mutex. This is because parsing the regexes is an expensive operation, but the size of that cache is not going to grow too much, as there is a limited amount of regex definitions.

If you can, please let me know if the latest master works in your setup, so we can release a new version.

[sgeef]

Hi Mati,

Thanks for your response, i was on vacation so just saw your responses right now.
Let me see if i can make some time this week to test if it works correctly and i'll come back to you with results.

[sgeef]

@YAGoOaR sorry for the delays, i will prioritise this asap, it's still on my list. To be continued..

[matisojka]

Hello @sgeef, any progress on this?

[sgeef]

@YAGoOaR sorry for the delay. We've started to test, but didn't see a big enough improvement, due to which we switch to different solution as we are on really high performance applications 1000rps +, so sadly can't confirm that it's really solved, though do remember that the code worked fine and had a bit of improvement for sure. So thanks for all effort. And i do really recommend your product to any other user which works on any normal application with support up until more or less 300rps. 👍

Feel free to close, and i do still agree that you should move forward with these changes as the unix philosophy is indeed preferred in my opinion.