This post originated from an RSS feed registered with .NET Buzz by Scott Hanselman. Original Post: Performance Counters in ASP.NET Feed Title: Scott Hanselman's ComputerZen.com Feed URL: http://radio-weblogs.com/0106747/rss.xml Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios. Latest .NET Buzz Posts Latest .NET Buzz Posts by Scott Hanselman Latest Posts From Scott Hanselman's ComputerZen.com

Did some great performance testing this last Sunday on the bank we're taking live soon.  We needed to get a few thousand users on the box, all banking at the same time.  The Host Interface side has some great performance counters that made it very easy to measure.  Even though they have a rich serious of counters, I added some counters to the UI side. 

As I've mentioned before, we describe our Domain Objects and Messages with XSD, and generate loads of C# code with CodeSmith (and some with XSLT).  Using these 'nouns' we create services (verbs) that act on them as they move through the system.  We build 1st class interfaces on top of a 3rd class router that basically does an Invoke/Execute/DoIt/IDispatch...a lot the way Invoke() works with ASMX WebServices. 

There's a whole vocabulary of messages that can be sent to Voyager, like 'GetAccounts' or 'AddPayment.'  Some come with Voyager and some are added for the implementation. 

Typically with Performance Counters there are either static counters, like 'Avg Bytes/sec' through the system, or instance counters like 'Bytes/sec on this hard drive.'  Often these instance counters are per process, or per piece-of-hardware. 

But since the verbs that head through the system can be dynamic, why not make new per counters as we see new verbs? (there's usually no more than 100, really usually <50)  So, on both the UI and HI we can look at instance Performance Counters like 'Time in (ms) for GetAccounts' or 'Bytes Out for AddPayee.' 

By adding the same counters but for an 'instance' that is really a verb, we can find out when a certain operation (verb) is not performing well on the system. 

And, since we can look at what the UI's round-trip time is (for example, 500ms) and what the HI's times are (200ms to the host, 150ms in the code) we can start measuring interstitial times like marshalling time, logging overhead, etc. at a very granular level.

Fortunately we baked in hooks to allow Performance Counters early on in the project.  You should to!  It's nice to REALLY know what's happening in your app.  The less of a black box your own app feels like, the more confident you can be when you make Service Level Agreements and predictions as to performance.  Nothing is more scary than NOT knowing how to measure your own application.

It was a good weekend.