Databases 9 min read

Why Merging Redis Requests Can Still Slow Your System – A Real‑World Debugging Tale

The author recounts a real‑world incident where consolidating many Redis GET calls into a single MGET reduced network latency but unexpectedly increased overall response time, leading to timeout errors; they detail the investigation using Redis slowlog, code analysis, and proper pagination techniques to resolve the hidden performance bottleneck.

MaGe Linux Operations
MaGe Linux Operations
MaGe Linux Operations
Why Merging Redis Requests Can Still Slow Your System – A Real‑World Debugging Tale

The author describes a recent incident where a new feature split cache keys, causing each piece of data to be cached multiple times and dramatically increasing the number of Redis requests per page load.

During peak traffic the system began generating a flood of timeout errors reported by Nagios, because the modified code caused each page to issue hundreds of Redis GET commands. The initial fix merged these calls into a single MGET, which reduced network latency but did not eliminate the timeouts. Further investigation revealed that the MGET now requested thousands of keys at once, leading to long Redis execution times (around 50 ms) and still causing timeouts.

The team used Redis slowlog commands to diagnose the problem:

CONFIG GET slowlog
CONFIG GET slowlog-max-len
SLOWLOG LEN
SLOWLOG GET

These commands showed a high frequency of slow logs and MGET commands with over ten thousand keys.

They also discovered that a page component fetched data from Redis based on a channel ID without specifying a limit, causing the MGET to retrieve all items in that channel.

Code Examples

A Python class representing the content model:

class Content:
    channel = int()
    data_size = int()

Example code for storing and retrieving blog posts in Redis:

import redis
cache = redis.StrictRedis(host='localhost', port=6379)
for post in posts:
    cache.set('blog:post:%s:title' % post.id, post.title)
    cache.zadd('blog:channel:1', time.time(), post.id)

# Pagination example
start = 0
count = 10
post_ids = cache.zrange('blog:channel:1', start, start + count - 1)
post_titles = cache.mget(map(lambda _id: 'blog:post:%s:title' % _id, post_ids))

The pagination logic originally assumed a limit of ten items, but because the channel model defaulted to a size of zero, the code sometimes retrieved the entire channel (using -1 as the end index), reproducing the performance issue.

Conclusion

In complex systems, hidden performance problems can arise from seemingly harmless code changes. Proper instrumentation, such as Redis slowlog, and careful handling of pagination limits are essential to avoid large, unexpected MGET operations that degrade latency.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

DebuggingRedisMGETSlowlog
MaGe Linux Operations
Written by

MaGe Linux Operations

Founded in 2009, MaGe Education is a top Chinese high‑end IT training brand. Its graduates earn 12K+ RMB salaries, and the school has trained tens of thousands of students. It offers high‑pay courses in Linux cloud operations, Python full‑stack, automation, data analysis, AI, and Go high‑concurrency architecture. Thanks to quality courses and a solid reputation, it has talent partnerships with numerous internet firms.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.