The source code for this can be downloaded from the Performance Counter eXtension page.
The code subscribes to three events using the Event System:
- Versioned items' (e.g. Pages or Components) save being initialised
- Versioned items' save being Processed
- 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.