cache slows down for large responses about graphql-ruby-fragment_cache HOT 4 CLOSED

Hi @duprasa, 27mb is a serious amount of data!

I guess you use Redis as a cache store (am I right?), so it might take some extra time for a network roundtrip. I wonder if it's possible to find out how much time is spent in parser and how long it takes to fetch a cached data (I guess we could compare how much time it takes to execute Rails.cache.fetch against redis.get).

from graphql-ruby-fragment_cache.

Hi @DmitryTsepelev thanks for the quick reply!

Ya it's a ton of data, we are planning on breaking it up into smaller requests, but I found that it illustrated this issue well.

I'm just using the default caching mechanism and running it locally, looking at the rails logs I can see that most of the processing is done in view_runtime, so the network isn't adding much overhead.

Smaller requests are blazing fast tho and range in the 10-100ms range 👍

I'm not great at rails so I have trouble diagnosing where the issue is exactly, do you think it might be because after cache.fetch, the data needs to be parsed to json (for graphql)? Maybe we can use a faster json parsing libary, I've heard that the deafult one is pretty slow?

Thanks again!

from graphql-ruby-fragment_cache.

Yeah, you could try writing a custom cache storage using a faster serialiser (example is is here, you need to implement only #read, #exists? and #write). I think oj should be faster then the default one. Before reimplementing storage, you can just compare how much time Rails.cache.read takes against oj.

from graphql-ruby-fragment_cache.

I'm closing the issue for now, feel free to reopen it or open a new one if you have questions 🙂

from graphql-ruby-fragment_cache.