“Light Requests Optimization” in AVIcode is perhaps one of the most complicated subjects. We get questions about it all the time. Today we will take a look under the hood of the AVIcode Agent and will discuss how exactly “Light Requests Optimization” works. Perhaps you have already noticed that some of the events have no stack collected and marked as “It is the light event” in details. Is it OK to get these? Yes. What do these events mean? In case Intercept Studio 5.7 User Manual does not provide enough enlightenment, please read below. There are certain functions within your application code that are responsible for processing user requests, executing business logic, etc. AVIcode calls them “entrypoints” meaning that all important stuff happens when these functions are executed. When a working thread steps into an entrypoint, AVIcode begins collecting relevant information it might need if something goes wrong. In fact, not all entrypoints will ever cause a problem. For example your application’s “Terms of Use” page might never cause a problem, and not because nobody ever reads it, but also because all it does is serving static content. Nevertheless AVIcode will thoroughly collect whatever it thinks is relevant every time the page is loaded, even though it is unlikely to ever become a problem. In real life production support does not jump out of the bed at 4:00 AM in the morning to respond to single performance event or one-off page exception. What is the point if it won’t happen after you show up, right? We only care about consecutive failures or performance events that are registered thousands or tens of thousands of times per day and disrupt the SLA. For these kind of problems, and for them only, we really need everything AVIcode can dig out. This is how AVIcode folks came up with “Light Requests Optimization” technique. Instead of collecting all the goodness from all of the entrypoints across your applications, AVIcode only does that for a smaller subset of “heavy” entrypoints, which had performance problems before. Now, how do they decide which entrypoints are “light” and which ones are “heavy”? Initially, all entrypoints are flagged “heavy”. When your application steps through a particular entrypoint for the first time the following happens:

• If entrypoint breaks the threshold, then the full stack trace is collected. The entrypoint remains “heavy” and will collect all of the stack trace data until you restart the application or **something else happens**.
• If entrypoint does not break the threshold for the first time, no event is collected and the entrypoint is considered “light”. It will remain “light” until it breaks the threshold. When it breaks the threshold the “light” event will be collected and the entrypoint will revert to “heavy”. After that it will remain “heavy” and will collect the full stack trace till you restart the application or **something else happens**.

Finally, I’d like to talk about that mysterious **something else happens**. There are three conditions under which AVIcode resets the “heavy”/”light” flags:

• When you restart the application (obviously). For IIS with web garden this may happen several times because there are multiple worker processes running.
• When you change the alerting threshold.
• When “Self Monitoring” feature activates the “back to light” function.

Apparently sometimes heavy-light optimization backfires. For example, if you are experiencing unusual system load due to maintenance, upgrade or your entire company trying to wrap up work before Thanksgiving, many entrypoints may become “heavy” because of the current system load. This is where the “Self Monitoring” features come to the rescue. We will discuss how it works next time. Meanwhile, short summary:

• “Light Requests Optimization” is your friend.
• It helps to reduce monitoring overhead in exchange for a small loss of diagnostic data.
• If you run into a “light” event look for more “heavy” events similar to that one. If you don’t see any – chances are you don’t care about the “light” event either.
• If you deal with the application that restarts frequently (e.g. pool of worker processes converting documents) it might be a good idea to turn the “Light Requests Optimization” off.

Cheers!