Description

Ideas:

• Build an APM solution in the XWiki code base itself in order to implement something similar to https://github.com/blog/1252-how-we-keep-github-fast
• Use the following framework for gathering metrics: http://metrics.codahale.com/getting-started/
• Replace the old "monitor plugin" by this solution
• Have some cheat mode to activate a top level metric bar in the XWiki UI (same as what github has done)
• Implement using Aspects so that all monitoring can be located in a single module. Note: It's a bit complex since we can't really chain aspect modules and we already have legacy modules... Maybe we shouldn't do this after all...
• Alternative solution to http://metrics.codahale.com/getting-started/: Use standard JMX MBeans (potentially with some helper library such as https://github.com/germanescobar/jmx-annotations) and then use JMXTrans to stream to Graphite/Ganglia/etc
• Install a Graphite Server on a xwiki.org VM and create perf dashboards in xwiki.org's Wiki for xwiki.org itself!
• Idea: Use Syren for Graphite alerting on thresholds

Here are some ideas of metrics to follow:

• Total server-side times by putting a Timer in XWikiAction.execute(). Note: don't forget REST calls too since they're currently served by a different Servlet
• Render time for a page (time spent in the Rendering module)
• Storage time for a page (time spent in the Database), with Timers in XWikiHibernate*Store
• Template render times, with Timers in XWiki.renderTemplate
• Stats performance timers
• Search indexing performance timers
• Total # of requests per second in the system
• # of requests done by EM and # of bytes downloads and times
• Times for displaying different subsystems:
  • Time to display the AS
  • Time to display the Tag cloud
  • etc. Can be found by digging in the top level times we'll get