Gavin - what kind of evidence do you need in order to take this patch into consideration? I haven't had the resources to perform proper load testing on it, but jrmithdobbs provides encouraging anecdotal data that suggests that the patch does indeed improve performance significantly.

The original implementation was synchronous and blocking: it allowed only one connection to be processed at once. My patch improves this behavior by rewriting the connection handling code to use asynchronous IO - enabling many connections to be processed at once. It should be clear why this improves performance.

https://github.com/bitcoin/bitcoin/pull/226

This patch set includes the following changes:

    Remove unused #includes

    Factor out #includes that are only needed in some source files from headers.h

    Add dependency tracking to unix, mac, and mingw makefiles via gcc's -MMD flag

These changes improve bitcoin's development environment. Previously changing any header file caused a global recompile. With these changes, only those files that directly depend on a changed header file will require recompilation.

As per http://bitcointalk.org/index.php?topic=6599.0.

This patch set updates bitcoin's RPC server to use boost::asio's async_read, _write, etc instead of their non-asynchronous versions.

The server still exists as a single separate thread, but the async calls should greatly improve performance under high load. The next step in robustifying the RPC server is to create a pool of threads for the RPC server, each of which handle a number of asynchronously reading and writing connections.


Pull request here: https://github.com/bitcoin/bitcoin/pull/214

I forgot to mention that the code already uses Boost/ASIO enough that making the RPC server code asynchronous is a pretty natural direction to go in.

As I understand it, it's not actually all that beneficial to spin off a new request thread for every incoming connection, at least in standard webservers. The general approach is to have a few worker threads processing requests, but each of them asynchronously. So one thread would be able to handle a few incoming connections at once by removing the sequential connection processing code.

I've had a look at the RPC server code and it doesn't seem like it would be that hard to get basic asynchronous IO going, which would help solve any timeout issues by itself. Of course you'd still need to put a lock around all of the actual bitcoin calls until that "one rpc thread" assumption is removed, but nonetheless I think it would be an improvement.

Does that sound like it could be a helpful patch? I'd like to get some feedback before doing any more work in this direction.