Monitoring Alfresco with New Relic

I came across New Relic a few days ago & decided after a few minutes that I HAVE to try out that cool.

1. Step – the Basics

My first step, adding a New relic agent to a tomcat server that runs Alfresco was pretty easy:

  1. SignUp to New Relic
  2. Download New Relics jar-Files
  3. Deploy them as described here:

After some minutes I was able to use the New Relic WebClient & try out some basic application monitoring features like:

  • HTTP Response Times
  • SQL Response Times
  • JVM Monitoring (CPU, Heap, GC etc.)
  • Transaction Traces etc

2. Step – Real User Monitoring

But the most impressive feature is their “real user monitoring” – They monitor the end user browser performance by automatically adding a small JS snippet to each HTML page. If you’ve JSPs that may be done automatically, but iId like to monitor an Alfresco Share application.


1st: A custom Freemarker TemplateMethod to be used within Share (or any other SURF webapp):

2nd: Spring Bean definition web-extension/custom-newrelic-context.xml:

3rd: Add ${newrelic.browserTimingHeader} & ${newrelic.browserTimingFooter} alfresco/templates/org/alfresco/include/alfresco-template.ftl

–> You’ll get some nice charts like these:

Alfresco Share datalist extensions – now Open Source!

I’ve developed some extensions to the default Alfresco Share datalists some months ago. My former blog post ( gained a lot of interests at Alfresco & also in the Alfresco Community.

As part of my discussions with fme’s customer and Alfresco regarding a contribution of this extensions one of Alfresco’s Solution Engineers did a code review and was very satisfied with it:!/rjmfernandes/status/136437605981097985

Finally fme’s customer agreed to make this extensions available under Open Source (Apache License) here:

This gives the whole Alfresco community the opportunity to use & improve the extensions we made. So, please feel free to contact me if you like to contribute back some additional features or if you like to sponsor the further development (e.g. an upgrade to 4.0).

Alfresco Share Cluster – tweaks

I recently faced an upgrade from a single node Alfresco into a high available (HA) configuration (1 Load-Balancer, 2 Alfresco Nodes, 2 Share Nodes) using Alfresco Enterprise 3.4.2 (including kerberos SSO etc.).

The Basic steps (@see Kevs blog post went well & my new system performed well. But then I realized that changes to a Share dashboard weren’t visible on the other Share instance. I forget to add the following configuration (“custom-slingshot-application-context.xml”):

But now my Share instances were very slow (dashboard layout changes weren’t visible on the other Share instance either). Loading a dashboard in the browser took up to 8s – without that cache disabling ~2s. Thus I made some tests with a vanilla 3.4.2 & 3.4.6 system and observed the same behavior (not as slow because I didn’t created a few hundred sites & >2000 users in my local system).

First of all I backported the 4.0.c org.springframework.extensions.webscripts.RequestCachingConnector that improved the whole Share performance a little bit. Afterwards I thought about the situations when a cached SURF object must be invalidated and reloaded via its remote store. AFAIK the only moment is when a dashboard configuration is changed on another Share instance. As my configuration only incorporates 2 Share instances I developed the follwing simple tweak to notify the other Share instance if a dashboard config is changed & the Surf object cache should be invalidated:

    re-enable caching for component & pages

  1. add a new HTTP endpoint (used to notify the other Share instance via HTTP if the SURF caches should be invalidated):

  2. append the following lines to site-webscripts\org\alfresco\components\dashboard\

  3. added a new Java-backed webscript (Share) mapped to URI api/fme/cache with following executeImpl():

The following things should be kept in mind:

  • this scenario only works with 2 Share instances & has to be enhanced if you’ve more than 2 nodes
  • api/fme/cache is not secured via an authenticator …

I’ll fill (& link) a detailed jira issue shortly.