5

I recently came across an extension called Performance Counter for Tridion here

There it mentions that it shouldn't be used in Prod environment as it runs on event system which might hit the performance of content manager. I want to know how much it is going to impact the CM so that we can decide whether we are ok to live with it or it isn't usable.

One more question would be, I am not able to see avg render time and item render time in perfmon even though i am publishing items. Am i missing anything other than deploying the performance counter dll into Content Manager and Publisher servers and configuring it in content manager config file.

  • 1
    Probably, it would be more efficient to contact to the author of this extensions directly. – Boris Ponomarenko Oct 17 '13 at 7:53
2

I created the Performance Counter eXtension quite a long time ago (more than 3 years ago actually) when SDL Tridion 2011 and its new event system model was released.

It was meant purely as an example of what could be done with the new event handlers, disregarding any performance impact it would have on the system. Hence the warning, as to what the exact impact is, that I have never measured, if you test it and don't see an issue, feel free to use it.

But you might want to look in its source and rebuild exactly according towards your requirements rather than just blindly use this. Keep in mind that any synchronous event handler you use will have a performance impact, but the impact can be as low as a millisecond (or less) such that you wouldn't ever notice it. The main point I tried to get across is that there is an impact, and you have to decide whether that is acceptable in your scenario or not.

With regards to the Avg. render time counter, you might want to start a debug session and see what is registered there. I know it worked (see the screenshot in my extension description), but it usually does give very low values. I might have done something evil in my Template code to get a useful reading (i.e. make the Template code really slow ;o)

| improve this answer | |
3

The source code for this can be downloaded from the Performance Counter eXtension page.

The code subscribes to three events using the Event System:

  1. Versioned items' (e.g. Pages or Components) save being initialised
  2. Versioned items' save being Processed
  3. RepositoryLocalObjects (e.g. Publish actions) being processed
public void Subscribe()
{
    EventSystem.Subscribe<VersionedItem, SaveEventArgs>(RegisterStartSaveTime, EventPhases.Initiated);
    EventSystem.Subscribe<VersionedItem, SaveEventArgs>(RegisterEndSaveTime, EventPhases.Processed);
    EventSystem.Subscribe<RepositoryLocalObject, SetPublishStateEventArgs>(RegisterEndPublishTime, EventPhases.Processed);
}

Subscribing to these three events in themselves should not be a very big overhead. I would suggest that Bart's recommendation to not use this as a monitoring tool on a Production system is due to these subscriptions being 'unnecessary', rather than particularly resource intensive.

More details on subscribing to Events System actions can be found in Bart's SDL Tridion 2011 .NET events article.

After the events are fired, the code uses the Win32 QueryPerformanceCounter and QueryPerformanceFrequency methods for adding the information to add counters under the 'SDL Tridion' Perfmon category.

If you are not seeing anything for the average render time, this would suggest that the RegisterEndPublishTime method is not being called (i.e. the Event subscription is not firing) or that there is an error getting or writing the Render time.

_renderTime.IncrementBy((long)item.RenderTime.TotalMilliseconds); 

You may want to check the System event logs and the Tridion event logs for errors here.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.