StackExchange / StackExchange/StackExchange.Redis

Question: Is ConnectionMultiplexer pool recommended?

Open
#1,279 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

⚙️ area:connection 🪠 connection pooling
Dominant language
C#
Stars
6.2k
Forks
1.6k
Avg merge
1d 15h
Merged PRs (30d)
43

Description

Hi, StackExchange.Redis library experts. This post is actually a question.

According to this documentation, only one ConnectionMultiplexer is needed.

I see my coworker creating a pool of ConnectionMultiplexers and each redis command is processed by one of ConnectionMultiplexers in round-robin way. His idea is that if a command is blocked for a long time, other commands can be picked up by other ConnectionMultiplexers. In our codebase, we use StringSetAsync, StringGetAsync, KeyDeleteAsync and Keys API. It seems like none of them is blocking operation(KEYS internally becomes SCAN). Is blocking possible in single ConnectionMultiplexer in our case? Should we change to single ConectionMultiplexer?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked Multiplexing documentation and compare its guidance with the reported ConnectionMultiplexer pool and round-robin usage. Review the stated StringSetAsync, StringGetAsync, KeyDeleteAsync, and Keys calls; done would require a decided recommendation about pooling and whether these operations can block a single multiplexer.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, redis
Domain
backend, databases
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.