Event Tracing for Windows (ETW) has been around for a while now, but many (if not most) developers have never used it. I’ve primarily used it for performance tracing, and it’s flexible enough to be used for logging regular application events as well. Read more on Performance Analysis with ETW: Event Tracing for Windows…
Even a thoroughly-tested application can wreck havoc if it hasn’t been tested in the context of a production-like system under production-like conditions.
Tools like Puppet and Chef make it easy to produce a production-like environment for testing, but what about the production-like conditions?
One aspect of these conditions can be approximated with load testing tools like JMeter or The Grinder. I recently used The Grinder to troubleshoot a performance problem with a small web application. Here’s a walkthrough of my process. Read more on Red Green Performance Testing with The Grinder…
While working with Patrick Bacon, migrating a large Ruby (ruby-1.9.2) web application from an older Solaris system to a new Linux system (Ubuntu 12.04 LTS), we discovered that the migrated web application seemed to be responding rather sluggishly. Comparing the logs, we found that the application was running, generally, about twice as slow on the new system as on the old system.
My first thought was hardware — the new system must be slower. Both systems were cloud servers, but hosted with different companies. Even though the Linux system was hosted on a much newer cloud platform, there was no guarantee that the underlying hardware was new or fast. But, at the same time, I just could not believe that the new system would be twice as slow.
I have seen some very nice, generic forms of memoization in the dynamic languages I’ve used. In languages like Ruby and Perl, for example, dynamically redefining a method to be a memoized version of itself is a good way to transparently handle it. However, I haven’t seen any examples of generic case memoization for C# methods that I’ve been happy with. So I took a stab at it.