cms
cms copied to clipboard
craftcms
[4.x]: GraphQL: Redis Cache-Component Performance Issue
What happened?
Description
When an entry with lots of Neo and Matrix fields is saved repeatedly (350-400 times), the GraphQL queries are really slow. For some reason the Redis Connection takes 800ms as opposed to 100ms without redis enabled. Now every Query regarding the entry are really slow and don't seem to speed up. Only fix is to create a new entry.
Steps to reproduce
- Save entry with lots of Neo and Matrix fields about 350 times
- Fetch entry through Graphql with all it's fields.
- Query is slow when using Redis as caching component
Expected behavior
Redis should be faster than the default cache component, right?
Actual behavior
Craft CMS version
Craft Pro 4.7.0
PHP version
No response
Operating system and version
No response
Database type and version
No response
Image driver and version
No response
Installed plugins and versions
What do the resources on your Redis instance look like when you get to this scenario?
And what is the eviction policy set to? https://docs.redis.com/latest/rs/databases/memory-performance/eviction-policy/
It's a default ddev docker redis install. So I would guess the policy is "volatile-lru". As for the resources, I am going to monitor and report back.
Check config/app.php – are you overriding the mutex component config to use Redis? If so, you can safely remove that as of Craft 4.6, as the default config now supports load-balanced environments.
Thanks for this information. I tried it without the mutex-component set to Redis but unfortunately the entries still take a long time to fetch from Redis-Cache
Redis should be faster than the default cache component, right?
Definitely not. Nothing is ever going to be faster than raw filesystem access (the default cache component). Redis involves a network connection, so will likely be slower. Redis, or any other centralized store, is only necessary when needed when a single filesystem isn't possible, like in a load-balanced environment.
Redis should be faster than the default cache component, right?
Definitely not. Nothing is ever going to be faster than raw filesystem access (the default cache component). Redis involves a network connection, so will likely be slower. Redis, or any other centralized store, is only necessary when needed when a single filesystem isn't possible, like in a load-balanced environment.
Oh, thanks for the clarification :)
Even though, I still find it odd that for entries, with lots of saves (300-400), fetching becomes slower. (It's also slower when using the filesystem as cache component, but not that noticable) I even deleted all revisions, but this didn't help. Am I missing something, or is it maybe a problem that involves the Neo plugin?
@DTesch-Reem could be that with Neo, the amount of cache data that’s being inserted into Redis becomes problematic. The larger the data, the more performance considerations
https://stackoverflow.com/questions/55517224/what-is-the-ideal-value-size-range-for-redis-is-100kb-too-large
Going to go ahead and close for lack of activity, but feel free to follow-up with any new info, and we can re-open as necessary.