AVIcode is a relatively simple product when it comes to the installation. Being installed in the default configuration, it can identify performance/exception violations in the.NET applications that even developers might not be aware about. However, to identify an issue and to provide enough details about it are two completely different stories. AVIcode really shines when it is configured properly, and there is a certain number of pitfalls that operations team should expect on the way from the default AVIcode configuration to the configuration that fits their environment.
There is a good reason for that, though. AVIcode is expected not to disrupt production environments. In the default configuration, it is only supposed to introduce up to 3-5% overhead, and that’s the reason why AVIcode does not collect a lot of troubleshooting data out of the box. So, one of the main goals of every AVIcode implementation is to provide such a configuration that will guarantee that AVIcode collects enough data to troubleshoot production issues when and if they occur.
For instance, imagine that there is an application that works with large XML files. XML processing is relatively slow, but this is the sort of performance callstack you will see for such an application:
This callstack does notify you that there is a performance issue, but it does not explain why. Assuming you have no access to the application source code, there is almost no way for you to identify the root cause of this problem. On the other hand, even if you sent this performance event to the development team, it is very likely they would not be able to figure out what’s the problem without asking you for additional details.
Compare the screenshot you saw above with the next one:
This time, the problem is almost obvious. Every time this application reads an xml file, there is a slowdown. Since it happens a few times per button click, all those smaller slowdowns add up, and application users start complaining about performance problems. And that’s exactly the sort of details you want to see for every performance issue.
What’s interesting, though, is that coming up with the proper configuration settings for every particular environment requires more information about the application than just the name of the executable. After all, you don’t want to start configuring the product when the problem occurs – that’s when you want to have enough troubleshooting data in AVIcode to resolve the problem.
Essentially, there is only one solution to that. Once AVIcode is installed, the next logical step is to bring in your application development team in order to come up with the configuration that will guarantee that all required namespaces and methods are monitored by AVIcode.
Here is the list of questions you may want to ask the dev team:
– – What thresholds should be configured for the web pages?
– – Which namespaces should be monitored?
– – What are the most interesting application methods that should be added to the configuration?
– – Are there noisy methods that should not be monitored since they will cause AVIcode to introduce much higher overhead?
The list may go on. In fact, in many cases it might be a good idea to answer this sort of questions in the test environment prior to rolling out AVIcode in production.
About the author
Alex Shlega works as a Senior Technical Consultant at VIACode Inc. Prior to this, Alex worked as a sustain engineering team manager at AVIcode.
See Alex’s blog for more AVIcode-related posts: http://gotchahunter.net/category/avicode/