Severe performance degradation of lightweight GET/SET operations after sending large MSET payload

[krasin-ga]

Describe the bug

I've noticed significant performance degradation of lightweight GET/SET operations after benchmarks that include MSET calls with a large payload.

The reproduction program runs in iterations. In each iteration, it measures latency of SET/GET on a fixed set of small keys, then issues an MSET with a growing number of large key/value pairs. As iterations progress, GET/SET operations on small, unrelated keys become steadily slower. The performance does not return to baseline between iterations, indicating an accumulating effect of large MSET payloads.

Example output from a single run:

Total time get/setting small values:
1. 00:00:00.2042555 // baseline execution time 
2. 00:00:01.6004488 // After MSET of 50 MB
3. 00:00:03.0718716 // After MSET of 75 MB..
4. 00:00:03.8109514
5. 00:00:03.7260123
6. 00:00:09.6063183

Despite identical GET/SET workloads, total execution time increases by more than an order of magnitude.

Steps to reproduce the bug

Reproduction program is available here:
https://github.com/krasin-ga/respsody/blob/main/util/Respsody.Util.Playground/Program.cs

Expected behavior

GET/SET operations on small keys should remain fast and consistent, even after performing large MSET commands. Total execution time should not increase noticeably between iterations.

Screenshots

No response

Release version

1.0.91 / v2.0.0-beta.1

IDE

No response

OS version

Windows 11 Pro 26200.7309

Additional context

No response

[vazois]

I am assuming that you are using mostly the default configuration. In that case, you might be running into too many collisions in the hash chain because of the index size being too small. Default value is 128m, maybe trying using 1g and let me know if you are still experiencing the issue.
Please share the server.conf file that you are using.

[krasin-ga]

In the reproduction example, a total of only 1,512 keys is used: 1,000 small and 512 large—so this issue is not caused by hash collisions. Additionally, connections to the same server that did not insert large values remain unaffected and maintain normal performance. This can be easily verified by using separate clients for operations on small and large values. I also verified that the issue is not caused by the client—similar behavior is observed with the StackExchange.Redis client.

Please share the server.conf file that you are using.

In the reproduction, Garnet is hosted in the same process as the client, using the default configuration:

using var garnet = new GarnetServer(
    new GarnetServerOptions
    {
        EndPoints = [ipEndPoint],
        logger = new ConsoleLoggerProvider(
                new OptionsMonitor<ConsoleLoggerOptions>(
                    new OptionsFactory<ConsoleLoggerOptions>([], []),
                    [],
                    new OptionsCache<ConsoleLoggerOptions>()))
            .CreateLogger("garnet")
    });

garnet.Start();