De-staticize the Runtime

[mwpowellhtx]

My assumption is that the Runtime needs to be invoked somehow, but I am not seeing that happen in my service application. No invocations are being intercepted.

However, I noticed that the Runtime is static. That's a concern because it makes for difficult to manage Dependency Injection.

See my SO for related question.

Do I need to invoke a discoverer somewhere along the way? Also, when I am installing my service, do I also need to "install" PerfIt? Or is this more of a "soft", runtime installation, than a service installation?

Finally, when is InstallStandardCounters invoked? These are probably more than sufficient for 80% of anything I'd need, but I'd like to also decouple those via DI if possible.

Sorry if these seem like obvious questions. I just want to understand it enough through and through so that I can deploy it properly.

[aliostad]

Hi @mwpowellhtx

The installation of counters usually happens at the deployment of your code, somehow with powershell or batch file using the Installutil.exe. They are not a part of the runtime experience, hence perhaps the term Runtime seems to be confusing on retrospect. I can change this in version 3.0 and move to another class.

Having said that, I loath making PerfIt dependent on any DI framework or even the abstractions since the code paths requiring testing in projects using this library does not involve these static.

Now, going back to installation, if you read the Wiki (there is a step-by-step guide) or you can find more info on my blog here.

[mwpowellhtx]

@aliostad I don't see a wiki. I went to the blog but I did not see any steps there either.

Perhaps I read the tests wrong but it seemed very coupled to Castle Windsor.

I use Autofac, and while there is DynamicProxy support, no connection is being made without registering all of the class and/or interface members. Members decorated with the attribute are not being intercepted.

I realize it is a fine line between the core functionlaity and a choose your own DI.

I am a little way out from a proper deployment, so really need "development" stage counters for analysis purposes, hence at least some of my confusion at the moment.

I am willing to consider contributing to a next version re-factoring around these areas if you are.

[aliostad]

No wiki??? What is it that you see when you go to https://github.com/aliostad/PerfIt?

[mwpowellhtx]

When I click the project's wiki I get a prompt to create the first page.

[aliostad]

I mean this:

---

PerfIt!

Windows performance monitoring and Event Tracing for Windows (ETW) instrumentation for .NET (including ASP.NET Web API)

FAQ

What is PerfIt?

PerfIt is a performance counter publishing library for .NET. With a little bit of setup, it painlessly publishes standard performance counters. What is also new in version 1.0, is the ETW events (ETW = Event Tracing for Windows) that can be published as part of instrumentation of the application. In version 2.0, you can set a SamplingRate so it does not generate a lot of data in case your system handles a lot of load.

Why should I use it?

If you are using .NET for a serious project, you need to instrument your code (and service). If you do not then PerfIt could do that easily without getting in your way to write your business logic.

What counters does it publish?

There are 5 standard counters that come with PerfIt out of the box (TotalNoOfOperations, AverageTimeTaken, LastOperationExecutionTime, NumberOfOperationsPerSecond and CurrentConcurrentOperationsCount) and you can choose one or all (typically you would choose all).

You can also create your own counters by implementing a simple base class.

What is the overhead of using PerfIt?

It is negligible compared to the code you would normally find within an API. It is within 1-2 ms.

Can I use it with ASP.NET Web API 2?

Yes, you can use it with any version of the ASP.NET Web API. There is a problem (that has a workaround) when registering Web API 2 which is an inherent problem with the InstallUtil.exe which does not honour AssemblyRedirect and the workaround has been discussed below.

What if I just want ETW events and no Performance Counters since installing them is a hassle?

You can turn only ETW or Performance Counters or both (or None).

I am using a library which publishes counters and I have my own counters in my project and I want to turn off library counters but keep mine?

As of version 2.1, you can control counters or raising ETW by their category name in your app.config (or web.config) appSettings. The syntax for category-based configuration is to have keys as "perfit::" where feature is one of "publishCounters", "publishErrors" and "publishEvent" and value is boolean. The previous global syntax of "perfit:" which turns features blanket on or off. [Bear in mind, appSettings overrides values set in code.]

Example:

In this case, publishCounters is globally on and publishErrors for category a is off.

Getting Started (Measuring any part of your code)

Please see the blog post Here.

Getting Started (ASP.NET Web API)

Step 1: Create an ASP.NET Web API

Use Visual Studio to create an ASP.NET Web API and add a controller (such as DefaultController).

Step 2: Add PerfIt to your project

In the package manager console, type:

PM> Install-Package PerfIt.WebApi
Step 3: Decorate your actions

In the actions you would want to monitor, add this attribute (we are using default counters so no need to specify them):

[PerfItFilter("MyApiCategory", Description = "My cool API"]
public string Get()
{
...
}
Step 4: Add an installer class

Right-click on your ASP.NET Web API and choose Add an Item and then from the menu choose "Installer Class".

Once added, click F7 to see the code and then add these lines:

public override void Install(IDictionary stateSaver)
{
base.Install(stateSaver);
PerfItRuntime.Install(Assembly.GetExecutingAssembly(), new FilterDiscoverer());
}

public override void Uninstall(IDictionary savedState)
{
base.Uninstall(savedState);
PerfItRuntime.Uninstall(Assembly.GetExecutingAssembly());
}
Step 5: Register your counters using InstallUtil.exe

In the command line, change directory to the .NET framework in use and then use -i switch to install ASP.NET Web API dll:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319>InstallUtil -i "c:\myproject\path\bin\MyAspNetWebApi.dll"
Step 6: Use your API and see the counters being published

Your counters will be published under a category, with the same name as your project. Underneath, you will see instance(s) of your individual counters.

counters

Common scenarios

Changing default category name

You can do this by supplying your custom category name to all three methods below (make sure they are all the same):

PerfItRuntime.Install("MyCategoryName");

// AND

PerfItRuntime.Uninstall("MyCategoryName");

// AND

var handler = new PerfItDelegatingHandler("MyCategoryName");
Changing default instance name

By default, instance name is composed of controller name and action name. If you have two actions with the same name (overloading a method), either you need to use ActionName attribute or change the method name (e.g. instead of Get using GetCustomer).

An alternative method is to supply instance name (also useful when you want to supply your custom name):

[PerfItFilter(Description = "Gets all items",
Counters = ...,
InstanceName="AnyName")]
public string Get()
{
...
}
Turn off publishing counters

For whatever reason you might decide to turn off publishing counters. All you have to do is to add this entry to the AppSetting of your web.config:

... ... As of version 2.1, there is option to turn on and off by CategoryName - see above.

Not to throw publishing errors

By default, publishing performance counters are regarded as having the same importance as the application's business logic and all publishing errors are thrown. If you would like to change this behaviour, you can do so both in code or in config:

PerfItRuntime.ThrowPublishingErrors = false;

Or by configuration:

... ... If you need to turn on or off publishErrors, publishCounters or publishEvents by category, please see examples above.

FileNotFoundException when registering the DLL using InstallUtil.exe

A common problem is to encounter FileNotFoundException when registering your counters using InstallUtil. This is more common when your use Web API 2. In any case, this is a problem with InstallUtil not honouring your assembly redirects. To solve the problem (and it is just a workaround), simply copy the assembly redirect directives to InstallUtil.exe.config, run the installation and then remove them.

This has been raised a few times (see the issues, for example #11) but the problem is simply the way InstallUtil works - or rather doesn't.

What I found the best solution is to include a copy of InstallUtil.exe and its custom config (which works for your project by copying content if assemblyBinding section of the web.config) along with your deployables and have a script to install the counter, rather than relying on the standard InstallUtil on the box. These files are small and certainly a good solution.

[mwpowellhtx]

The steps to install anything are unnecessary IMO, especially considering I can make unit tests pass by providing categories.

I'll have a baseline PR ready today to build on, perhaps as early as today, with some baseline improvements. All passing the tests, but for a Task.Delay issue.

It's funny you mentioned "context" in another message. One key improvement will be promotion of the Contexts Tuple to a first class IDisposable InstrumentationContext. That cleans up the Instrument and InstrumentAsync operations significantly. I think you will like it.

After which I'll have a look at common elements necessary to extend into any DI, and re-factor that, while introducing a PerfIt.Autofac.DynamicProxy project as we discussed.