As I mentioned, I’ve been adjusting my build system and have finally got to the point where my lock inversion detector is suitable to run on all of my example servers during their test phase on the build machines. I’m working my way through the various example server’s test scripts and adjusting them so that they use the lock inversion detector, can be easily configured to run the full blown deadlock detector and also can run the servers under the memory profiling test runner that I put together earlier in the week.
My theorising about the strange memory related failures that I was experiencing with my distributed testing using WinRS have led me to putting together a test runner that can limit the amount of memory available to a process and terminate it if it exceeds the expected amount. With this in place during my server test runs I can spot the kind of memory leak that slipped through the cracks of my testing and made it into release 6.
Previously on “Practical Testing”… I’ve been looking at the performance of the timer system that I developed and have built a more specialised and higher performance timer system which is more suitable for some high performance reliable UDP work that I’m doing. Whilst developing the new timer wheel I began to consider the thread contention issues that the timer system faced and came up with a notation for talking about contention (see here).
Previously on “Practical Testing”… I’m writing a timer wheel which matches the interface used by my timer queue. This new implementation is designed for a particular usage scenario with the intention of trading space for speed and improving performance of some reliable UDP code. The last entry completed the development of the timer wheel. This time we fix a couple of the bugs that I’ve discovered since I started to integrate the code with the system that it was developed for.
Previously on “Practical Testing”… I’m writing a timer wheel which matches the interface used by my timer queue. This new implementation is designed for a particular usage scenario with the intention of trading space for speed and improving performance of some reliable UDP code.
Over the last four entries I’ve implemented various parts of the timer wheel and adjusted the test code so that I could reuse the tests that I already had for the other implementations with my timer wheel.
Previously on “Practical Testing”… To deal with some specific usage scenarios of a piece of general purpose code I’m in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. Last time I left myself with a failing test. The problem is that setting a new timer on the timer wheel sets a timer that’s relative to the time that timer wheel thinks is ’now’ and the timer wheel’s view of the current time could be slightly behind reality; see the previous entry for a diagram that explains the problem.
Previously on “Practical Testing”… To deal with some specific usage scenarios of a piece of general purpose code I’m in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. The timer wheel trades space for speed and so far the development has gone well as I’ve been able to use the tests that I had already developed for the previous implementations to guide the new development.
I’m in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. The idea being that for certain specific usage scenarios the timer wheel will perform better than the timer queues. Last time I refactored the tests that I was using for the timer queues to remove duplication and I now have a set of failing tests for the new timer wheel.
The most recent articles in the “Practical Testing” series have been discussing the performance of the timer queue that we have built. Once I had got some new, optional, performance tests in place to measure what we were trying to improve I eventually came up with a new approach and began to implement a timer wheel that conforms to the interface used by the other implementations of my timer queue. Whilst doing this it became obvious that there was duplication in my test code and so the tests have been refactored to remove the duplication of the test code between CCallbackTimerQueue and CCallbackTimerQueueEx and, in addition, to create a full suite of tests for the new CCallbackTimerWheel class.
The most recent articles in the “Practical Testing” series have been discussing the performance of the timer queue that we have built. As I hinted when I first brought up the performance issues, the particular use case that I have which is causing problems might well be more efficiently dealt with using a different (more specialised and less general purpose) design.
The timer queue has adequate performance for general purpose use and can handle timers set within a range of 0ms to 49.
