AVIcode 5.7: Performance pitfalls of chatty functions

If you enable AVIcode monitoring, it will monitor a very limited set of methods by default. There will be page loads, SQL calls, web service calls, and some other methods. But AVIcode will capture no data for your application methods.

Why is that?

The reason is really simple. One of the goals AVIcode has declared long ago is to provide application monitoring in the production environments. However, when it comes to the production environments, potential performance overhead becomes really important. So, out of the box AVIcode monitors only those functions which must be monitored in order to capture application data. If you need to capture additional details, you will have to instruct AVIcode Agent to do it, and that’s when you will have to decide if you are willing to trade performance for having those additional details captured for you.

AVIcode implements a bunch of performance optimizations to let you get away with it. Sometimes, though, you should be really careful about changing AVIcode configuration settings.

In particular, if you have a chatty namespace, you should be careful about selecting the functions you want to monitor. Here is what you may want to consider:

1. You can enable monitoring of the whole namespace in the Intercept MMC Console. In this case, AVIcode will capture duration of any method call if that method belongs to your namespace (and if the method is supposed to show up on the stack at all of cause). As an alternative, you can enable monitoring of a particular class from that namespace.

2. You can enable monitoring of particular functions in the Intercept MMC Console. In this case, AVIcode will be monitoring your function as a “resource”, and, comparing to the scenario above, AVIcode will capture not only the duration of your function calls, but it will also provide information about all the parameters of such calls.

Apparently, the second method is supposed to be slower. Normally, it does not matter that much. However, there are some extreme situations when it really matters.

You can try this:

1. Create an win form application
2. Add a button to the form, and create a button_click for that button
3. Define a function in your application that does almost nothing:

private int InnerCall(int counter)
{
  int res = 1;
  while (counter > 0)
  {
    res += InnerCall(0);
    counter–;
  }
  return res;
}

4. Call that new function from the button_click and pass 500000 as a parameter: InnerCall(500000)

Compile your application, start it, and measure button_click time when there is no AVIcode monitoring. Most likely, execution time will not exceed a second or two.

After that, enable monitoring (with 0 thresholds), and add your application namespace to monitoring. Next time you start the application, AVIcode will instrument all namespace functions. However, it will only capture durations of the calls in this mode. If you do the same test, you may be able to notice some slowdown, but it will be almost unnoticeable.

Finally, add InnerCall as a resource function in the Intercept MMC console. AVIcode will have to use a much heavier instrumentation this time, and, if you do the same test, that’s when you will really notice the slowdown. For instance, on my virtual machine execution time went from less than 1 second to approximately 15 seconds during this test, and that’s for only 500000 calls.

What this test shows is that there is a certain price you have to pay for monitoring. Most of the times you can safely ignore it. However, if you put AVIcode into the situation when it has to collect information about a lot of function calls for every event, the price may go up.  That’s especially important for the “resource” functions (those added in the “resources” area of the Intercept MMC console), and that’s somewhat important for the functions added through namespaces/classes.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.