StackExchange.Redis
StackExchange.Redis copied to clipboard
StackExchange
Question: Is ConnectionMultiplexer pool recommended?
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?
In my experience there is merit to this idea, you can also be blocked in the sense a command in the queue is returning a large payload and your simpler command is stuck waiting for its response to be complete.
In my experience there is merit to this idea, you can also be blocked in the sense a command in the queue is returning a large payload and your simpler command is stuck waiting for its response to be complete.
Hello, what can I do for large payload, I can't make the payload shorter due to business need, is there anything can I do it doesn't timeout?
There is a fun conflict here, that we are looking into future options for:
- in general, if you have high volumes of small operations: multiplexed connection sharing is hugely beneficial - reducing packet fragmentation etc
- however, if you have large payloads, it jams the pipe and a lot of small ops can get nuked by a single large op
Assuming you're only talking about network, not tying up the actual server (think "keys *", etc), then: for now, using different multiplexers for "large slow things" and "quick small things" is a good idea. We are looking into what we can do internally to avoid this conflict, perhaps using multiple connections internally and automatically. We don't have the code for all of that today, but it is something I am keen to explore. This also allows us the option to look into supporting blocking operations via a leased connection.
On Tue, 11 Feb 2020 at 14:41, Humayun Ahmed [email protected] wrote:
In my experience there is merit to this idea, you can also be blocked in the sense a command in the queue is returning a large payload and your simpler command is stuck waiting for its response to be complete.
Hello, what can I do for large payload, I can't make the payload shorter due to business need, is there anything can I do it doesn't timeout?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/StackExchange/StackExchange.Redis/issues/1279?email_source=notifications&email_token=AAAEHMDTUFRGDWFE6TWOG4DRCK2INA5CNFSM4JO3QZY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELMVCNI#issuecomment-584667445, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEHMDJAUYIB6LASTNMTZTRCK2INANCNFSM4JO3QZYQ .
-- Regards,
Marc
Hi, Is there any update on supporting some sort of connection pooling internally in the library ? And if so , is there some estimate of ETA ? If this is not planned currently , how would you recommend using multiple connection multiplexers ?
