6

The socket classes in .NET have got some new async methods (like Socket.ReceiveAsync).

I'm trying to understand their purpose. As I understand it, they were created to avoid making a new IAsyncResult object for each operation.

Let's say that I were to create a high performance HTTP server. Then I need to create a Request or a Response object for each operation. And the request or response objects certainly have some properties that might be other classes too (or just primitives + string). And I might have to fetch information from a database (more objects to create).

My point is that quite many objects can be created per request/reply. Is the AsyncResult objects so heavy that it would affect performance of a complete server? Or do MS mean that I should use flyweight pattern (reusing request/reply objects instead of allocating new ones) for all my objects in the server ?

Please enlighten me.

Update

From MSDN about the new Async methods:

The main feature of these enhancements is the avoidance of the repeated allocation and synchronization of objects during high-volume asynchronous socket I/O. The Begin/End design pattern currently implemented by the System.Net.Sockets.Socket class requires a System.IAsyncResult object be allocated for each asynchronous socket operation

Source: http://msdn.microsoft.com/en-us/library/system.net.sockets.socketasynceventargs.aspx

Update2

This question is not a duplicate. I'm not asking about the difference. I'm well aware of the difference. If they added the methods to reduce allocations and the work for the GC, should I do the same in my protocol layer on top of the socket handling? i.e. should I use the flyweight pattern for objects like HttpReqest etc.

Cœur
  • 37,241
  • 25
  • 195
  • 267
jgauffin
  • 99,844
  • 45
  • 235
  • 372
  • My understanding was that `ReceiveAsync` is offered because so many people *struggle* with `IAsyncResult` etc - not due to any "heaviness" of `AsyncResult`... – Marc Gravell Jun 03 '11 at 12:56
  • Alex Turner gave a presentation on async at teched a couple of weeks ago, might want to get ahold of him: http://northamerica.msteched.com/speaker/details/Alex_Turner – Allen Rice Jun 03 '11 at 13:02
  • Good discussion here (both about differences in semantics & performance): http://stackoverflow.com/questions/5764921/whats-the-difference-between-beginconnect-and-connectasync/5765032#5765032 – Teoman Soygul Jun 03 '11 at 13:17
  • @Mark Gravell: Check my update. – jgauffin Jun 03 '11 at 13:33

2 Answers2

2

Well in one socket lifetime each begin/end operation will allocate new sync object.

For example, your logic is,

// GET /default.aspx HTTP/1.1<cr-lf>
ReadLine for Http Verb and Version
// Headers
ReadLine till you get empty line and process header
// Data
Read or process mime data

Now if you notice, we will never read everything in one begin/end call instead each operation will invoke multiple begin/end which will create new sync object.

But these all steps are for only one client/server communication.

So your request/response object will be only one throughout the lifetime of socket and in this case you are better off using new Async method and leave your request/response object as just one single object.

When you have a server processing 1000 requests simultaneously this will certainly impact performance. Even if sync object takes 100 bytes but allocation/reallocation, gc processor usage all will affect for 1000 simultaneous operations.

However well designed algorithms exist for memory management, if your server will run continuously for long time, it will certainly cause fragmentation and it does slow down.

Akash Kava
  • 39,066
  • 20
  • 121
  • 167
  • HTTP might have been a bad example. Let say the SIP protocol instead which involves lots of objects (transactions, multiple messages for the same request/reply, sessions) etc. Should I create pools for all of those? When do I know when I can shrink the pools (i.e. dispose reused objects)? – jgauffin Jun 09 '11 at 19:59
  • Transactions, messages and replies per communication step will mostly contain few strings and value types. These types does not affect performance so badly compared to IAsyncResult because IAsyncResult contains some thread synchronization mutex or semaphore etc, maintaining and creating more object of such type hurts performance as RunTime needs to process them in every event causing more and more hit on CPU and memory. Reusing simple value types will make little difference compared to costly resources. – Akash Kava Jun 10 '11 at 02:27
0

Not a direct answer to your question but there were a couple of good presentations on async at tech ed. You'll have to create a login to view them

DEV324 C# and Visual Basic Future: Async Made Simple Wednesday, May 18

DEV335 Improving Your Microsoft ASP.NET Application Performance with Asynchronous Pages and Actions Thursday, May 19

Allen Rice
  • 19,068
  • 14
  • 83
  • 115