Asynhronous Socket Operations
Working with sockets in .NET is done with the
Socketclass. From the MSDN documentation, the recommended approach is to use the asynchronous methods such as
ReceiveAsync. These methods register callbacks to be executed when data arrives or ships through the socket. As a result of the callback approach, no threads are blocked by slow connections.
Sockets and F# Async
Unfortunately, the default interface is not very intuitive. The example code is atrocious. Since the operations are callback-based, this seems like a good match for
F# async. I went for the first mapping that came to mind:
Implementing this interface is easy - it is just working around the boilerplate: creating a
SocketAsyncEventArgsobject, registering a callback, calling the method, checking the result for errors. I was able to express all of it in a single helper method:
It seems that the common optimization paths include pooling sockets, pooling
SocketAsyncEventArgs, and pooling buffers to prevent memory fragmentation. The latest point is the most interesting. Socket code itself is written in unmanaged C and passing data between garbage-collected .NET code and C code is done by pinning the .NET array used as a buffer. A pinned array is never relocated by the garbage collector, so the C code
has no trouble finding it. A lot of pinned arrays to work around make garbage collector's job harder - memory gets fragmented.
To avoid fragmentation issues, instead of allocating a lot of small arrays I allocate one huge array and then lease sections of it to be used as buffers by the socket operations.
I have not yet tried pooling `Socket` or `SocketAsyncEventArgs` objects in a similar manner.
For benchmarking I have used Apache Bench (ab) tool running on Arch Linux inside a VirtualBox VM. All benchmarks involved dynamically generating and serving a "HELLO, WORLD" document on my Core i3 laptop, with
ab -k -c 1000 -n 10000:
|Server||Keep-alive r/s||Regular r/s|
|Haskell warp/wai GHC 7||3500||3500|
I do not feel very good about these numbers, in particular because I have seen claims of Haskell WARP doing 90000 r/s on only slightly faster hardware (8-core Core i5). It may be that I am hitting VirtualBox networking overhead or I have not built the Haskell code with proper flags.
But for what they are worth, the numbers seem to indicate that F# async is a good enough foundation for web servers with performance in the IIS league. It does not need to be faster, it just needs to be good enough. The real advantage is that F# async code is tremendously easier to read and write than explicit callback code.
EDIT: Please do take the benchmarks with a grain of salt. They are far from comprehensive or correctly done.