.NET networking performance considerations?

[cjard]

Hello All

I'm looking for some articles on implementing high performance server applications in .NET and the various techniques for dealing with connections and sending/receiving data.

The server is simple request/response like HTTP. The last time I wrote some network heavy apps, I managed all the threading myself, making two new threads to work on the reading from andd writing to the socket, then placed them in the threadpool to be run. Performance was surprisingly bad, with one bittorrent client on another machine initiating enough low-volume connections to cause massive CPU usage.
Upon switching to Asynchronous style IO, the CPU usage dropped dramatically.

It is recommendations of this sort that I seek

For now, I will probably implement this in the same style as I did before. A main loop runs to accept connections (this will be a windows service):

While True

  tcpc As TcpClient = myTcpListener.AcceptTcpCLient()

  tcpc.BeginRead(...delegated call..)

End WHile

Other questions:

Socket or TcpClient? Do we care?


I dont think this server will be hit with much traffic, probably less than 10 requests per second, but it would be nice to not have to take it offlien to patch stuff up later..

 

[JohnH]

I would say use the TcpClient if you can, it is just a Socket with "default" settings with a NetworkStream wrapped around.

I have also noticed the big performance gain with async methods compared to Threads for many fast (short) network operations.

 

[cjard]

I would say use the TcpClient if you can, it is just a Socket with "default" settings with a NetworkStream wrapped around.

I have also noticed the big performance gain with async methods compared to Threads for many fast (short) network operations.

I noted that, but thne I see articles which lead me to beleive that the async is nothing special, and every call to BeginXXX simply starts another thread (or retrieves one from a pool) to wait on the blocking socket for whatever it is XXX

e.g.

We have Thread1, and it is proceeding. Thread1 Runs the BeginAccept() method
The CLR creates/de-pools another thread, thread2, and thread2 blocks on the socket
Thread1 finishes all the code it has to do and exits
Thread2 awakes when the operation unblocks and the first thing Thread2 does is call EndAccept, to get reference to the socket, then it calls BeginAccept, which creates/de-pools another/Thread1 to wait on the socket again

In a lot of ways, i cant really see the huge difference between this and sync if you code in some way like:

While True
  Socket s = listener.AcceptSocket()
  new Thread(new ThreadedWorkerOnSocket(s)).Start()
  'or
  ThreadPooling.GetSpareThread(new ThreadedWorkerOnSocket(s)).Start()

I'm wondering if there is anything in .NET like java.nio which is singlethreaded IO (from tha pplication point of view.. the underlying OS may still use threads to read and write data from buffers to e.g. sockets)..

Just wondering, basically, whether .NET's threads in this sense are implemented as O/S threads ; in java the java thread is an application level implemntation, and the jvm, representing an ideal computer, will swap the java threads around.. the whole thing running in a single O/S thread that could be conceptualised like a CPU.

If .net threads are o/s level, then sure.. not going to gain much, and i'm sure that MS will have worked har dto make .NET io, threading and buffering as native based as possible, maybe even directly mapping the buffers that .NET io uses to the exact area of memory associated with the socket.. data arrives, and is written to memory, it doesnt then need copying into .NET's space.. but i dont know..

 

[JohnH]

This thread seems to indicate that device drivers are used for async socket and IO calls, and not threadpool.