Magento 2 Redis performance issue
Issues were discovered during our work under Magento SaaS multitenent (magneto.com) platform.
Redis Performance Degradation with SINTER:
/SINTER command was discovered:
SINTER key [key …]
Fairly High Time complexity: O(N*M) worst case where N is the cardinality of the smallest set and M is the number of sets.
Returns the members of the set resulting from the intersection of all the given sets.
Time complexity: O(1) for every call. O(N) for a complete iteration, including enough command calls for the cursor to return back to 0. N is the number of elements inside the collection.
The SCAN command and the closely related commands SSCAN, HSCAN and ZSCAN are used in order to incrementally iterate over a collection of elements.
In Magento 2 Redis KEYS command has been warned against being used in production as it can block the database while the query is being performed. Remember Redis is single threaded!
The chart below shows the effects of running SCAN/SINTER. It shows the effects that running the queries has on the existing workload’s performance.
For the above, memtier was used to generate a workload, and a specific numbers of SCAN queries was run to see the effects on the workload.
The baseline ops/sec without running SINTER was ~128,000 ops/sec. It is obvious that as more SINTER,SCAN,KEYS queries in Magento are performed, the workload throughput becomes greatly reduced. The cumulative blocking effect of the many iterations becomes apparent fast. This means it is important to reduce the number of SINtER queries being performed to prevent reducing performance drastically.
Tracking the number of commands processed is critical for diagnosing latency issues in your Redis instance. Because Redis is single-threaded, command requests are processed sequentially. T
Avoid slow commands for large sets: If increases in latency correspond with a drop in command volume you may be inefficiently using Redis commands with high time-complexity. High time-complexity means the required time to complete these commands grows rapidly as the size of the dataset processed increases. Minimizing use of these commands on large sets can significantly improve Redis performance. The table below lists the Redis commands with highest time-complexity. Specific command attributes that affect Redis performance and guidelines for optimal performance are highlighted for each of the commands.
intersect multiple sorted sets and store result
intersect multiple sets and store result
intersect multiple sets
transfer key from one Redis instance to another
return serialized value for a given key
. ZREM remove one or more members from sorted set
SORT sort elements in list, set, or sorted set
SDIFFSTORE subtract multiple sets and store result
SDIFF subtract multiple sets
SUNION add multiple sets
LSET set value of an element in a list
LREM remove elements from a list
LRANGE get range of elements from a list
. add multiple sorted sets and store result
Magento 2 Backend cache implementation has many long running Ridis kommands (SINTER etc.) commands when models and caches were changed or flushed by tag. Almost any write operation running SINTER operations. That’s why during real production workload Magento performance is so disgusting. When you are changing something Magento black Redis entirely on 1–2 seconds sometimes more and any other requests can’t be handled.