Last time I explained how the managed side of my flexible hosting server architecture was structured. I dealt with the IDL required to generate the COM interfaces which were used to communicate between unmanaged code and managed code and detailed how the custom AppDomainManager object allowed me to load and execute managed code in such a way that it was easy to update the managed applications whilst the server was running.
I’m working on some prototype code right now to improve the “deployment characteristics” of a socket server that I wrote for a client which uses CLR hosting to provide multiple managed applications within a single unmanaged host. The client wants to be able to start, stop and restart individual managed applications within the server so that during development or when a managed application is updated they don’t need to restart the whole unmanaged server process to use a new version of a managed application.
I’ve recently been adjusting my CLR hosting code as a client wanted to be able to host the .Net 4.0 runtime. Previously they were hosting the 2.0 runtime and, as I mentioned a while back, the hosting API has changed with 4.0.
Switching to hosting 4.0 was easy enough but being able to fall back to hosting 2.0 on a machine where 4.0 wasn’t installed is slightly more complex. It’s reasonably obvious (you need to make sure that you call GetProcAddress() to bind to CLRCreateInstance() rather than linking to it at build time), but Brad Wilson has a nice list of steps to show how it’s done here on his blog.
Yesterday I had a bug report from a client who had a user that was getting an exception report from their software which simply said “GetTempPath() - Failed to get temp path”. Now as error messages go this isn’t the best but it comes from some code that has been in my tools libraries for around 10 years and which has never failed before, it has no tests, we’re probably lucky that the message didn’t just read “TODO” as I’m pretty sure that it’s the first time that anyone has ever seen it apart from by reading my source code or running strings on an exe that includes my source code… Anyway…
As I mentioned yesterday, I’ve been doing some performance testing using the command line interface to perfmon to record the results. Today I automated the stuff I was playing with over the weekend and ended up with a script that can set up a perf log trace, install a particular build of a service, run a test from a remote client machine (using winrs) and then stop and remove the perf log and the service.
Whilst profiling my new low contention buffer allocator in a ‘real world’ situation recently I spent quite a lot of time trying to work out what I was looking for and when it should happen. Since the allocator improves performance by reducing lock contention it only shines when there IS lock contention. I added some more monitoring to the existing buffer allocator so that it can give an indication of when it’s going to block during an allocation or release operation (by using TryEnterCriticalSection() followed by a monitoring notification and then an EnterCriticalSection() when the try has failed).
I’m continuing to help my performance obsessed client squeeze more out of his server. As always we’ve been using perfmon to view the server’s performance counters and since we were investigating CPU spikes we were interested in the thread activity counters that the server exposed.
The various perfmon enabled example servers that ship with The Server Framework have always exposed counters that show the number of active and processing threads from various thread pools.
The new release of the licensed, high performance, I/O completion port, server framework includes lots of new example clients and servers; the framework now comes with 74 fully working example that showcase various aspects of the framework.
Since the UDP side of the framework has undergone a lot of work recently to support filtering and in preparation for the release of several reliable UDP protocols there are lots of new UDP server examples.
The latest release of The Server Framework gives you the option of building with FILE_SKIP_COMPLETION_PORT_ON_SUCCESS enabled for various parts of the framework. You can enable it for stream and datagram sockets independently and also for the async file reader and writer classes. This option potentially improves performance by allowing overlapped I/O that completes straight away to be handled by the thread that issued the I/O request rather than by a thread that is servicing the I/O Completion Port that the socket or file handle concerned is associated with.
I’ve been working on some performance tuning for a client of mine recently and whilst much of the tuning has been specific to the details of the their particular server design, eventually I can always get to the point where there are some improvements that can be done to the framework itself. It’s nice to have a “real world” performance tuning scenario as I find that tuning example servers can be pointless as the example may not match a real world scenario.
