C# – Performance of ReceiveAsync vs. BeginReceive

asynchronouscperformancesocketstcp

I'm currently programming a client application and I'm wondering whether I should use the Socket class' ReceiveAsync or BeginReceive method. I have been using the latter so far, however, I found that it seems to stress the CPU quite a bit. Here is what my receive loop basically looks like:

private void socket_ReceiveCallback(IAsyncResult result_)
{
    // does nothing else at the moment
    socket.EndReceive(result_);
    byte[] buffer = (byte[])result_.AsyncState;

    // receive new packet
    byte[] newBuffer = new byte[1024];
    socket.BeginReceive(newBuffer, 0, newBuffer.Length, SocketFlags.None, 
                        socket_ReceiveFallback, newBuffer);
}

Now I've been wondering if I am doing something wrong here, since other applications that communicate hardly stress the CPU at all. And also I'm wondering if I would be better off with using SocketAsyncEventArgs and ReceiveAsync.

So here are my questions:

Why is my loop stressing the CPU so much?
Should I use SocketAsyncEventArgs and ReceiveAsync instead of BeginReceive?

Best Answer

I have been benchmarking synchronous vs. asynchronous socket on on a localhost loopback connection. My results were that the asynchronous version was about 30% slower. That was surprising to me considering that async IO is all the rage now. It didn't matter how many threads I used. I could use 128 threads and still synchronous IO was faster.

The reason for that is, I believe, that async IO requires more allocations and more kernel mode transitions.

So you could just switch to synchronous IO, if you don't expect hundreds of simultaneous connections.

Related Solutions

C# – Reusing SocketAsyncEventArgs with ReceiveAsync results in infinite loop

If your socket is set up for a byte stream then you may get a callback with zero bytes, this indicates that a graceful closure of the socket has occurred and that no more bytes will ever be read. Simply check for this in your code, e.g.

private void ProcessReceive( SocketAsyncEventArgs e )
{
    AsyncUserToken token = e.UserToken as AsyncUserToken;
    if( e.ByteTransferred > 0 && e.SocketError == SocketError.Success )
    {
        // .. process normally ..
    }
    else
    {
        CloseClientSocket( e );
    }
}

private void CloseClientSocket( SocketAsyncEventArgs e )
{
    AsyncUserToken token = e.UserToken as AsyncUserToken;
    try
    {
        token.Socket.Shutdown( SocketShutdown.Send );
    }
    // throws error if it's already closed
    catch( Exception ) {}
    token.Socket.Close();
}

Of course you'll also need to stop your client from trying to use the socket, but I'm sure you can work that part out.

Sqlite – Improve INSERT-per-second performance of SQLite

Several tips:

Put inserts/updates in a transaction.
For older versions of SQLite - Consider a less paranoid journal mode (pragma journal_mode). There is NORMAL, and then there is OFF, which can significantly increase insert speed if you're not too worried about the database possibly getting corrupted if the OS crashes. If your application crashes the data should be fine. Note that in newer versions, the OFF/MEMORY settings are not safe for application level crashes.
Playing with page sizes makes a difference as well (PRAGMA page_size). Having larger page sizes can make reads and writes go a bit faster as larger pages are held in memory. Note that more memory will be used for your database.
If you have indices, consider calling CREATE INDEX after doing all your inserts. This is significantly faster than creating the index and then doing your inserts.
You have to be quite careful if you have concurrent access to SQLite, as the whole database is locked when writes are done, and although multiple readers are possible, writes will be locked out. This has been improved somewhat with the addition of a WAL in newer SQLite versions.
Take advantage of saving space...smaller databases go faster. For instance, if you have key value pairs, try making the key an INTEGER PRIMARY KEY if possible, which will replace the implied unique row number column in the table.
If you are using multiple threads, you can try using the shared page cache, which will allow loaded pages to be shared between threads, which can avoid expensive I/O calls.
Don't use !feof(file)!

I've also asked similar questions here and here.

Related Topic