1

I recently debugged a performance issue with how I was using SslStream.

The client is C#/.NET and had the following Stream configuration

  • Raw Socket/NetStream
  • Wrapped by BufferedStream
  • Wrapped by SslStream
  • Wrapped by "protocol" stream (which sends bytes/ints/strings etc)

I was seeing extremely slow performance when sending data from a client to a server, across the internet where it was taking a long time to serialise information on the client side.

Removing SSL stream and the connection sped up to expected levels.

Then I changed the above stream configuration to be..

  • Raw Socket/NetStream
  • Wrapped by SslStream
  • Wrapped by BufferedStream <-- moved this
  • Wrapped by "protocol" stream (which sends bytes/ints/strings etc)

And the connection sped up to expected levels.

Can someone explain why changing the stream configuration helps the performance so much?Particularly as I tested the original configuration with the client on the same machine as the server at it ran very quickly?

Mike Q
  • 22,839
  • 20
  • 87
  • 129

1 Answers1

7

The reason is simple. You save an int (just 4 bytes), it gets wrapped into SSL packet and then buffered. After you changed the order, you started to collect lots of data in the buffer, which was then wrapped with SSL as one large block. Less SSL wrappers, higher speed.

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • Thanks that makes sense. Is it the case that SslStream doesn't have an internal buffer as such, it will just encrypt and send what you give it each time you call write()? Plus I'm not sure I fully understand why speed-wise it is ok when the client is on the same machine as the server? – Mike Q Feb 19 '13 at 20:00
  • @MikeQ SSLStream doesn't know how much data you plan to write, so it sends every piece you pass to it separately. As for speeds on local vs remote system - it's implementation-specific so one can only guess. – Eugene Mayevski 'Callback Feb 20 '13 at 07:39