Sync Vs. Async Sockets Performance in .NET

Everything that I read about sockets in .NET says that the asynchronous pattern gives better performance (especially with the new SocketAsyncEventArgs which saves on the allocation).

I think this makes sense if we're talking about a server with many client connections where its not possible to allocate one thread per connection. Then I can see the advantage of using the ThreadPool threads and getting async callbacks on them.

But in my app, I'm the client and I just need to listen to one server sending market tick data over one tcp connection. Right now, I create a single thread, set the priority to Highest, and call Socket.Receive() with it. My thread blocks on this call and wakes up once new data arrives.

If I were to switch this to an async pattern so that I get a callback when there's new data, I see two issues

1. The threadpool threads will have default priority so it seems they will be strictly worse than my own thread which has Highest priority.

2. I'll still have to send everything through a single thread at some point. Say that I get N callbacks at almost the same time on N different threadpool threads notifying me that there's new data. The N byte arrays that they deliver can't be processed on the threadpool threads because there's no guarantee that they represent N unique market data messages because TCP is stream based. I'll have to lock and put the bytes into an array anyway and signal some other thread that can process what's in the array. So I'm not sure what having N threadpool threads is buying me.

Am I thinking about this wrong? Is there a reason to use the Async patter in my specific case of one client connected to one server?

UPDATE:

So I think that I was mis-understanding the async pattern in (2) above. I would get a callback on one worker thread when there was data available.开发者_开发知识库 Then I would begin another async receive and get another callback, etc. I wouldn't get N callbacks at the same time.

The question still is the same though. Is there any reason that the callbacks would be better in my specific situation where I'm the client and only connected to one server.

The slowest part of your application will be the network communication. It's highly likely that you will make almost no difference to performance for a one thread, one connection client by tweaking things like this. The network communication itself will dwarf all other contributions to processing or context switching time.

Say that I get N callbacks at almost the same time on N different threadpool threads notifying me that there's new data.

Why is that going to happen? If you have one socket, you Begin an operation on it to receive data, and you get exactly one callback when it's done. You then decide whether to do another operation. It sounds like you're overcomplicating it, though maybe I'm oversimplifying it with regard to what you're trying to do.

In summary, I'd say: pick the simplest programming model that gets you what you want; considering choices available in your scenario, they would be unlikely to make any noticeable difference to performance whichever one you go with. With the blocking model, you're "wasting" a thread that could be doing some real work, but hey... maybe you don't have any real work for it to do.

The number one rule of performance is only try to improve it when you have to.

I see you mention standards but never mention problems, if you are not having any, then you don't need to worry what the standards say.

"This class was specifically designed for network server applications that require high performance."

As I understand, you are a client here, having only a single connection.
Data on this connection arrives in order, consumed by a single thread.

You will probably loose performance if you instead receive small amounts on separate threads, just so that you can assemble them later in a serialized - and thus like single-threaded - manner.
Much Ado about Nothing.

You do not really need to speed this up, you probably cannot.

What you can do, however is to dispatch work units to other threads after you receive them. You do not need SocketAsyncEventArgs for this. This might speed things up.

As always, measure & measure.
Also, just because you can, it does not mean you should.
If the performance is enough for the foreseeable future, why complicate matters?