A long time ago when I wrote my first article on high performance TCP/IP servers for Windows using IO Completion ports over on CodeProject I complained that “Also the more complicated examples, ones that used IO completion ports for example, tended to stop short of demonstrating real world usage. After all, anyone can write an echo server… “
Yet here I am, three and a half years later with a huge collection of different kinds of echo server.
For the last week or so I’ve been working on measuring and improving the performance of The Server Framework. The latest release of the free version of my asynchronous, windows, IOCP based, socket server framework can now be obtained from here at ServerFramework.com.
This week I’ve had several potential new clients asking about performance numbers for various aspects of the system and so I thought it best to do some measuring.
This is quite nice, a whole list of finely targetted RSS feeds for Knowledge Base articles for various products.
Last year I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code.
The code under test was intended to be very scalable, I use the code to provide light weight asynchronous timers for my socket server framework and the idea is that each connection might have several timers associated with it.
I’ve been spending some time pushing the limits of The Server Framework, my IO Completion Port based socket server framework, to see how many connections my servers can handle and what happens when system resources run out. Earlier postings on the subject are here and here.
This morning I fired up one of my older server boxes and ran the server on that rather than on my dev box. It effortlessly managed 64000 concurrent connections.
But mostly me. ;)
During yesterday’s investigations into handling lots (30,000+) of socket connections to a server built with The Server Framework I took a few things for granted. I should have been a bit more thorough rather than just assuming I knew what I was doing.
Today I did some more tests.
I was a little surprised that flicking the switch on my server framework so that it posted zero byte reads had no affect on the limit of connections that I could support.
This CodeProject entry is SO full of errors and poor practice that I must find the time to leave a comment on it…
[Updated: 29th October] Done. Comment is here.
I’m doing some research for a potential client. They need a TCP/IP server that handles ’lots’ of concurrent connections. Their own in-house server code currently fails at 4-6000 connections and I’m putting together a demo for them of how The Server Framework supports 30000 connections on 1GB of ram before running into non-paged pool restrictions… Whilst doing this I ran into an ‘interesting’ feature of WSAAccept() (or, perhaps, simply of an LSP that’s installed on my machine…).
I’m upgrading one of my build machines to use the April 2005 edition of the Platform SDK to investigate the implications of this posting over at eggheadcafe.com which states that since Visual Studio 6 ceased to be supported as of the end of September 2005 the last version of the Platform SDK that will work with Visual Studio 6 was the February 2003 version.
There has been quite a lot of discussion in the comments of my Bluetooth code sample about the ‘broken’ uuid.
I guess it’s a combination of wine, Pink Floyd and the fact that this week the world wants to remind me that I’m older than I feel. Thoughts drift back to the past. Times past and friends forgotten.
A long time ago, in a galaxy far, far away I used to play an online game called MUD II. This was back when you had to use your modem to dial another modem to get a connection to the world and there was no such thing as “the internet” unless you could connect to a university computer somewhere (like Essex Uni, perhaps).
