Wednesday, October 31, 2007

Been a little quiet here lately

I've just become very aware that I haven't posted here since Friday's cynical link about BP being fined, but things have been busy here finalising and deploying the update hinted at in my Monitoring Custom Windows Services post.

It's not been an easy couple of weeks, but I think we're finally seeing the performance improvements that we were hoping for.

I know I mentioned posting some code samples about how to create your own performance counters, but I really haven't had time.

If you want to investigate using performance counters then probably the best thing to do is check out these MSDN articles:

Friday, October 26, 2007

BP fined for environmental crimes and fraud

BP has been fined $373m by the US government for "environmental crimes and committing fraud".

"BP has committed serious environmental crimes in our two largest states, with terrible consequences for people and the environment," the Environment Protection Agency said.

Anyone else remember their advertising campaign that encouraged people to calculate their "carbon footprint"?

Seems BP should get their own house in order before telling the rest of us to.

Thursday, October 25, 2007

Monitoring Custom Windows Services

A lot of my work at Esendex involves creating and maintaining Windows Services that form the guts of a much larger product that we collectively call the Esendex Messaging System. The work that these services do can differ wildly: everything from the relatively mundane to complex critical services that the business depends on.

Because of this, each service needs to be monitored in different ways. Sometimes its OK to trawl through log files to discover what the service is doing, but with other more widely used services this quickly becomes tedious.

We're currently in the process of rolling out an update to one of our critical Windows Services, and this update involves an architecture change that makes examining logs beyond tedious, it's actually unworkable for anything other than tracking historical events.

This is where we use custom performance counters. If you're a developer and don't know what these are, then read up on it, and quickly. Performance counters can be used to give you visibility on the near-realtime progress of your systems.

Here are some examples of what we monitor with performance counters:

  • Execution time of certain key interface methods,
  • Total counts of current throughput at various stages of a message's journey through the system,
  • Rates of current throughput (how many messages per second, etc),
  • Statuses of key services.
From these we can use the standard Windows Performance Monitor to watch what a service is doing. For a more bespoke monitoring solution you can also write your own applications that read your performance counters and display the results in a more friendly way.

If I get time I'll knock up some sample code demonstrating how to do this.

Friday, October 19, 2007

The Vulcan Flies Again

Something I've been waiting to see for a few years after hearing that the Vulcan to the Sky Trust were restoring one: yesterday it completed its first test flight.

Check out some of these photos of the flight.

Thursday, October 18, 2007

Couple of things I miss from Visual C# Express

I know this great little application is free and so can't really complain, when you work with Visual Studio 2005 Professional five days a week the bits that are missing start to get to you:

  1. No "delete all breakpoints" option.
  2. Can't attach the debugger to another process, or set the project to load a different application
Doesn't sound like much, and I didn't think that was much, until you step through an XNA project, and then have to manually remove all your breakpoints. Or if you want to unit test something and you can't attach to the NUnit process, which means you can't step through your tests.

Glad it's got Intellisense though :)