The Evolution Profiler utility provides you with information about how the page was loaded, as well as how long each part took to load.  Once installed and configured, it will add a small overlay in the top left of the screen, showing the time it took the current request (and any subsequent callbacks on the page).  Clicking on one of these links will open up a popup providing more details about the page load (see Reading trace results below for more detail).

This is perfect for troubleshooting cases where specific pages are taking longer to load than expected as it will allow you to narrow down exactly where the performance issue is located.  This tool may be of less help if you’re experiencing site wide performance issues – it will help if there is one particular cause on every page that’s being slow, but will not help in the case of a load related issue where everything is running slow, as the information it gives is too specific.  The tool also profiles the execution of AJAX requests, so can be used to troubleshoot performance issues with scripted file callbacks, REST requests or other AJAX requests.

The source code is available on GitHub



(Note, this plugin only supports Telligent Community 7+ and Telligent Enterprise 4+)

  1. Download the installation package.
  2. Copy the contents of the /deploy/ folder to your Telligent Community or Telligent Enterprise web folder
  3. Go to the Manage Plugins Page in your community
  4. Enable the “Performance Profiler” plugin.

There are a number of configuration options you can use to customise the profiler results.  These can be accessed by going to the plugin’s configuration, and are all documented on that page.

Who can see Trace Results

You don’t want all your users to see your trace results.  For starters the information is likely to be distracting to many of your users, but may also pose a security risk by exposing the internals of how the page is rendered.  Because of this,

  • All requests made from the web server itself will display performance results
  • Users whose username is in the list of Allowed Usernames option under the plugin’s configuration
  • Users who are in any of the roles listed in the Allowed Roles option under the plugin’s configuration

If you want to make profiler results visible to everyone (e.g. for a development environment), include ‘Everyone’ in the list of allowed roles.

Reading trace results

Events taking a trivial, amount of time (by default less than 2ms, but can be configured in the plugin’s configuration) are excluded.  These can be displayed by pressing the show trivial button at the bottom of the profiler popup.  Events are also shown up in a hierarch.  For example the “[page] building container of content-fragments” event will have a number of “[widget]” events in it for each widget rendered. 

Each event has three values with it. 

  • duration – the time spent inclusively.
  • duration with children - If the event has no children it will be the same as the duration.  If an event does have children, this value will be the sum of the durations of the current event and it’s children.
  • from start – how long after the request first began did the event begin.

Many events have a prefix in square brackets which categorise the event.  The main events you’ll see in the Main events you’ll see

  • [aspnet] - Represent phases of the ASP.Net pipeline
  • [header],[page],[footer]: Represents the rendering of the header, page body or footer regions of a page
  • [widget-header] -  The rendering of a widget's header script
  • [widget] - The rendering time for the main widget body.
  • [executed-file] - This occurs whenever a widget view is being rendered typically by a widget callback, or when a widget/widget callback calls $core_v2_widget.RenderView(...) to render another view.
  • [sproc] - Execution of a stored procedure in the core of Telligent Evolution.  Will not show sproc execution in Calendar

A couple of notes about reading the performance results

  • If you see a long time in the MapRequestHandler stage of the ASP.Net pipeline, then that is probably due to ASP.Net recompiling the ASPX page you're requesting.  This should be a one time hit per page, per application lifecycle, although refer to the ASP.Net documentation for more details on this.
  • If you see a lot of time being spent in [cfs] events, then look at the Disk performance on the servers containing your CFS, and the network connectivity/latency between your web servers and the filestorage servers.
  • Remember that due to caching, the times different parts of the page take to render may vary significantly from request to request.  Entire widgets may be cached, or just the data the widgets have to get from the database to process.  If you’re seeing part of the trace taking a long time, which shows up again and again after refreshing, it may be a candidate for doing some Caching work.
  • There are currently no trace events logged around search.  Since search makes network IO calls, these can take some time.  If a widget which is using search is taking a long time, you’ll need to do further investigation to identify if the search calls are the cause of the problems or not.
  • The hiding of trivial results does not respect the trace result hierarchy. 

Note, the profiler will not trace events in your custom code.  To record events from your custom code, you’ll need to explicitly add the tracing code yourself.  See for more details.

Disabling the Plugin

Note that even after disabling the plugin in the Control Panel, there will still be some remnants wired up which will result in a performance overhead.  To totally remove these, you should totally remove the plugin from your community by delete the files you copied in step 1 of the installation instructions from your community.