Again, I’d like to thank Igal Tabach­nik and SharpCrafters for invit­ing me to do the webi­nar, the record­ing of the ses­sion is now avail­able on their Vimeo channel.

Pseudo Real Time Per­for­mance Mon­i­tor­ing with AOP and AWS Cloud­Watch from SharpCrafters on Vimeo.

 

Per­for­mance Mon­i­tor­ing with AOP and Ama­zon Cloud­Watch

View more Pow­er­Point from Yan Cui

 

Source code is avail­able at http://aop-demo.s3.amazonaws.com/RTPerfMonDemo.zip

Share

Fol­low­ing my recent webi­nar with SharpCrafters on how to setup pseudo real-time per­for­mance mon­i­tor­ing using Aspect Ori­ented Pro­gram­ming and Ama­zon Cloud­Watch, I’d like to say thanks to the guys for hav­ing me, it was a great fun Smile

For any­one inter­ested, the source code is avail­able at:

http://aop-demo.s3.amazonaws.com/RTPerfMonDemo.zip

If you want to run the demo con­sole app to gen­er­ate some data, you need to put your AWS key and secret in the App.config file in the Demo.ConsoleApp project:

image

Just go to aws.amazon.com and cre­ate an account, you’ll then be given an access key and secret to use.

The slides for the ses­sion is also avail­able to down­load on SlideShare:

Enjoy!

Share

I will be doing a webi­nar with the good folks of Post­Sharp on the 22nd March to talk about the use of AOP and AWS Cloud­Watch as a pseudo real-time per­for­mance mon­i­tor­ing tool (see high-level overview here).

It’s a free webi­nar, it runs from 22nd March 3PM4PM GMT, the reg­is­tra­tion link is here.

 

Hope to see you there Smile

Share

This is some­thing I’ve men­tioned in my recent AOP talks, and I think it’s wor­thy of a wider audi­ence as it can be very use­ful to any­one who’s obsessed with per­for­mance as I am.

At iwi, we take per­for­mance very seri­ously and are always look­ing to improve the per­for­mance of our appli­ca­tions. In order for us to iden­tify the prob­lem areas and focus our efforts on the big wins we first need a way to mea­sure and mon­i­tor the indi­vid­ual per­for­mance of the dif­fer­ent com­po­nents inside our sys­tem, some­times down to a method level.

For­tu­nately, with the help of AOP and AWS Cloud­Watch we’re able to get a pseudo-realtime view on how fre­quently a method is exe­cuted and how much time it takes to exe­cute, down to one minute intervals:

image

With this infor­ma­tion, I can quickly iden­tify meth­ods that are the worst offend­ers and focus my pro­fil­ing and opti­miza­tion efforts around those par­tic­u­lar methods/components.

Whilst I can­not dis­close any imple­men­ta­tion details in this post, it is my hope that it’ll be suf­fi­cient to give you an idea of how you might be able to imple­ment a sim­i­lar mechanism.

AOP

A while back I posted about a sim­ple attribute for watch­ing method exe­cut­ing time and log­ging warn­ing mes­sages when a method takes longer than some pre-defined threshold.

Now, it’s pos­si­ble and indeed easy to mod­ify this sim­ple attribute to instead keep track of the exe­cu­tion times and bun­dle them up into average/min/max val­ues for a given minute. You can then pub­lish these minute-by-minute met­rics to AWS Cloud­Watch from each vir­tual instance and let the Cloud­Watch ser­vice itself han­dle the task of aggre­gat­ing all the data-points.

By encap­su­lat­ing the logic of mea­sur­ing exe­cu­tion time into an attribute, you can start mea­sur­ing a par­tic­u­lar method by sim­ply apply­ing the attribute to that method. Alter­na­tively, Post­Sharp sup­ports point­cut and lets you mul­ti­cast an attribute to many meth­ods at once, and allows you to fil­ter the method tar­get by name as well as vis­i­bil­ity level. It is there­fore pos­si­ble for you to start mea­sur­ing and pub­lish­ing the exe­cu­tion time of ALL pub­lic meth­ods in a class/assembly with only one line of code!

Cloud­Watch

The Cloud­Watch ser­vice should be famil­iar to any­one who has used AWS EC2 before, it’s a mon­i­tor­ing ser­vice pri­mar­ily for AWS cloud resources (vir­tual instances, load bal­ancers, etc.) but it also allows you to pub­lish your own data about your appli­ca­tion. Even if your appli­ca­tion is not being hosted inside AWS EC2, you can still make use of the Cloud­Watch ser­vice as long as you have an AWS account and a valid AWS access key and secret.

Once pub­lished, you can visu­al­ize your data inside the AWS web con­sole, depend­ing on the type of data you’re pub­lish­ing there are a num­ber of dif­fer­ent ways you can view them – Aver­age, Min, Max, Sum, Count, etc.

Note that AWS only keeps up to two weeks worth of data, so if you want to keep the data for longer you’ll have to query and store the data your­self. For instance, it makes sense to keep a his­tory of hourly aver­ages for the method exe­cu­tion times you’re track­ing so that in the future, you can eas­ily see where and when a par­tic­u­lar change has impacted the per­for­mance of those meth­ods. After all, stor­age is cheap and even with thou­sands of data points you’ll only be stor­ing that many rows per hour.

Share

Oh, the Pain!

Now and again we all come across an object which requires ini­tial­iza­tion before it can be used but with noth­ing there to stop us from try­ing to use it before it’s initialized.

In most cases you will get a seem­ingly unre­lated excep­tion (e.g. null ref­er­ence when the object tries to use some resource which it expects to be set dur­ing ini­tial­iza­tion), which aren’t very help­ful at all when you try to debug/identify the problem.

If you’re lucky, the object you’re using might have been designed with this in mind and gives you a mean­ing­ful excep­tion when you try to call a method which requires the object to be ini­tial­ized first, in which case it should be a straight­for­ward to fix your code accord­ingly. For the guys design­ing the class though, this usu­ally means they have to lit­ter their code with val­i­da­tion logic and often means dupli­cated val­i­da­tion code or unnec­es­sary inher­i­tance just to encap­su­late the val­i­da­tion logic.

For­tu­nately, with the help of Post­Sharp, a sim­ple attribute can take care of this chore for you with ease!

Define high level interface

First off, you need a nice and sim­ple inter­face like this:

/// <summary>
/// Marks a component which needs to be initialized before it can be used
/// </summary>
public interface IInitializable<T>
{
    bool IsInitialized { get; }

    void Initialize(T initObject);
}

Ini­tial­iza­tion­Re­quire­dAt­tribute

The attribute will look some­thing like this (in Post­Sharp 2):

[Serializable]
[AttributeUsage(AttributeTargets.Method, Inherited = false)]
public sealed class InitializationRequiredAttribute : MethodInterceptionAspect
{
    public override bool CompileTimeValidate(MethodBase method)
    {
        // make sure that the attribute is used in a type that implements the 
        // IInitializable interface
        if (!method.DeclaringType.GetInterfaces()
                   .Any(i => i.IsGenericType &&
                             i.GetGenericTypeDefinition() == typeof(IInitializable<>)))
        {
            throw new Exception(string.Format(
                "The [{0}] attribute can only be used in types that implement the [{1}] interface",
                GetType(), typeof(IInitializable<>)));
        }
        return base.CompileTimeValidate(method);
    }

    /// <summary>
    /// Checks the IsInitialized property before allowing the call to proceed
    /// </summary>
    public override void OnInvoke(MethodInterceptionArgs eventArgs)
    {
        var propertyInfo = eventArgs.Instance.GetType().GetProperty("IsInitialized");
        if (propertyInfo != null)
        {
            var propertyValue = propertyInfo.GetValue(eventArgs.Instance, null);
            if (propertyValue != null && propertyValue is bool && (bool) propertyValue)
            {
                // only proceed with the call if the instance has been initialized
                eventArgs.Proceed();
                return;
            }
        }
        throw new InstanceNotInitializedException(eventArgs.Method.Name);
    }
}

I have enforced a rule that this attribute can only be used in a class which imple­ments our IIni­tial­iz­able inter­face, you can relax this rule by remov­ing the over­rid­den Com­pile­TimeVal­i­date method. How­ever, in my expe­ri­ence it’s best to not leave any grey area in your code just in case you run into a sit­u­a­tion where you had expected the attribute to do its job only to find out later that something’s gone wrong because you had accidentally/purposely removed the IIni­tial­iz­able inter­face from your class.

Usage

To use the attribute:

public class MyClass : IInitializable<string>
{
    public bool IsInitialized { get; private set; }
    public void Initialize(string initializationData)
    {
        …
        IsInitialized = true;
    }

    [InitializationRequired]
    public void DoSomething() { }
}
Share