I’m in the process of upgrading another client to v6.0. These guys write multi-user game systems and have a fairly complex CLR hosting custom application server. Anyway, I was hoping that we’d have a few easy performance wins from the changes that have gone into v6.0 and these gaming guys are possibly even more hung up on performance than my banking and trading clients.
The good news is that the changes in how we convert numbers to strings has drastically improved performance in their debug builds where they have lots of logging going on.
Herb Sutter has just published an interesting article over at DDJ on correctly using thread pools: Use Thread Pools Correctly: Keep Tasks Short and Nonblocking.
It’s not rocket science and it doesn’t deal with platform issues but it’s a useful summary of why The Server Framework’s thread pools operate as they do. Note that on Windows you can use IO Completion Ports to manage the work queue into the thread pool and this can keep the number of threads that are scheduled to run at the optimum number so that the pool operates at the ‘correct load’ for most of the time even in the presence of blocking tasks.
A user of my free server framework code has reported an error and supplied a fix.
The problem is that he’s been having connections closing and returning ERROR_CONNECTION_ABORTED and the free code doesn’t handle this situation very well and this was causing his I/O threads to terminate and leaving him with an unresponsive server. Interestingly I’ve never had this problem reported before and haven’t been able to duplicate the issue but I thought it would be useful to publish the fix in case anyone else comes across the problem.
A lot of the custom development work that we do for our customers can be classified as developing ‘custom application servers’. Development for these kinds of servers usually requires that we design a wire-protocol for communications between the clients and the server, implement a server that either does everything that the customer requires or allows them to easily plug in their business logic and provide a client side library (or two) that makes it easy for the customer to write clients for the server.
I’m in the process of upgrading a set of ISO8583 servers for a client. One of these is the original server that caused The Server Framework to come into existence back in 2002. The other two servers are based on a 2005 cut of the code; one written in 2005 and one, heavily based on the other, written in 2008.
The upgrade is primarily to support windows performance counters on Windows Server 2008 and to allow for x64 builds.
Mark Russinovich has an excellent piece (here) on how ’non-paged pool’ memory sizes are calculated for various versions of Windows operating systems. As those of you who are dealing with high performance, high connection, server systems know, non-paged pool is one of those annoying system wide limits that can sometimes get in the way of servicing a large number of clients as every active I/O operation consumes some non-paged pool. The good news is that on Vista x64 systems and later the way that non-paged pool limits are calculated has changed and the limits are much higher.
The latest, 6.0, release of The Server Framework is significant for me in several ways. From a purely practical point of view it’s the first release from my new Subversion repository and as such it’s the culmination of a fair amount of work and restructuring. The new repository is easier to work with and the new code structure is expecially noticable in the way that example servers and clients are now packaged for release.
The latest release of The Server Framework is now available. This release includes the following changes.
The following changes were made to the libraries.
Admin Library - 6.0
Added back the Admin\VC6Compatibility directory with sal.h for VS.Net (2002) and VS 2003. The directory is now called Admin\Compatibility and you need to copy sal.h to your compiler’s include directory if it complains about it being missing.
Some more changes with how Admin.
The log file rotation code that I wrote a while back has been working well for several clients. Recently someone suggested that the design of their server’s logging meant that they tended to generate lots of useful information on server start up and server shutdown and then nothing until the server had problems. This meant that they were ending up with lots of empty log files as the hourly, or daily, or weekly rotation period would create a new file and most of the time nothing would be written to it.
I developed the new SChannel SSL adapter for The Server Framework in a mostly test driven style; a while ago I called this Just In Time Testing… It worked well and, to be honest, I couldn’t imagine developing code as complex as the SChannel adapter without tests; though as I noted when I first set out on the development, back in 2001 I’d developed the corresponding OpenSSL adapter without any tests at all… The tests worked well for me this time around and I was able to both learn about the SChannel API that I was using and implement the required code far easier with the tests in place.
