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.

SCAN

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.

ZINTERSTORE

intersect multiple sorted sets and store result

SINTERSTORE

intersect multiple sets and store result

SINTER

intersect multiple sets

MIGRATE

transfer key from one Redis instance to another

DUMP

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

. ZUNIONSTORE

. 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.