2

I'm currently successfully using the windows port of Redis (2.8.19 - MS Open Tech) via the stackexchange.redis (1.0.4) and the windows RedisSessionStateProvider (1.6.2) providers for storing sessions on premise.

Comparing this configuration vs InProc session state for sessions we noticed about 20% decline in performance under high load. In hopes of reducing the performance gap, I'm wondering if serializing sessions with protobuf-net can help out - the models have the necessary proto attributes but not entirely sure how to configure the sessionStateProvider to serialize with it.

Has anyone got this working? Did the performance improve?

Also, if there are any other suggestions to reduce the performance gap that would be great as well.

EDIT: here are the session keys/sizes for the app (measured similarly to this method: How to find out size of session in ASP.NET from web application?)

session key1 size: 38kB
session key2 size: 30kB
session key3 size: 37kB
session key4 size: 35kB
session key5 size: 35kB
session key6 size: 43kB
session key7 size: 33kB
session key8 size: 28kB
session key9 size: 42kB
session key10 size: 31kB
**TOTAL SESSION SIZE: 352kB**

Thank you in advance.

Community
  • 1
  • 1
Mikalee
  • 289
  • 3
  • 14

1 Answers1

2

It is normal and expected that an out-of-process store is going to be slower than in-process: by definition, in-process has nothing to do, whereas you now need to construct commands, traverse TCP, let the server software do its thing, traverse TCP back to the caller, process the response, and deserialize. That's a lot of stuff!

It is tricky to answer the serialization question because the performance characteristics depend hugely on your models. There are 4 costs of interest here:

  • serialization CPU
  • payload size (directly impacts network bandwidth)
  • network latency
  • deserialization CPU

It wouldn't amaze me if the existing provider is using BinaryFormatter, in which case it is indeed possible that the CPU and bandwidth numbers could be lower with a different serializer such as protobuf-net. If the dominating factor is latency: you can't do much.

As an aside: for some of our internal uses we actually use protobuf-net and GZipStream: we find that since our data tends to contain quite a bit of text, the reduced bandwidth from gzip out-weighs the additional CPU to serialize/deserialize.

But the most important question: how much data is in your sessions?

The only way to get meaningful answers for your specific usage is: to measure it.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Thanks Marc, I certainly know/understand that an out-of-process store can't be as fast as inProc considering the factors you mentioned - didn't mean to imply redis/providers are inefficient by any means. I've added the size of our session keys to my question above - if any more info would help (such as the actual models) please let me know - and thanks for your help! – Mikalee Apr 15 '15 at 22:05
  • @Mikalee at that size, bandwidth and (de)serialization are non-trivial, so I would suggest it is definitely worth trying protobuf-net; most session providers know to pass `byte[]` through without overhead, so get it to that via `MemoryStream` – Marc Gravell Apr 15 '15 at 22:22
  • thank you, if you have the time, it would be great if you have any pointers on how to go about doing that, I'm not sure where to start. Thanks again – Mikalee Apr 16 '15 at 14:43