Main goal for collecting these metrics is to tailor our test setup according to real customer scenarios.

Prio 1:

• Number of sites / pages (MAGNOLIA-9207, MAGNOLIA-9208)
• Number of pages per publish (MAGNOLIA-9212)
• Amount of Content-items in workspaces (MAGNOLIA-9209)

Prio 2:

• Concurrent editors? (MAGNOLIA-9210)
• UI Action execution stats? (MAGNOLIA-9211)

Next:

• Installed modules (there already)
• Number of observation listeners
• CPU vs. IO vs. memory/gc when under load
• Asset volume
• Amount of workspaces
• Amount of Content types
• Amount of Content apps
• Size of versions workspace
• JR index sizes
• Amount of users
• Amount of definitions
• Magnolia Cache hit/miss ratio (ehcache)
• Number of publications
• Overall size of JR repo

Notes / Links

• Metrics and priorities
• Way to obtain metrics and short/long term strategies
• Instrumentation modules on PaaS, configuration, documentation
• Access to and insight from current user metrics

Tasks

• Devise JR SQL statements to determine
  • Number of sites/pages
  • Items per workspace for the workspaces we are interested in
• Determine whether and which logger write output that could be used to unearth information about
  • Publications and its volume (e.g. number of pages)
  • Concurrent editors (e.g. logins / logouts, JR sessions, servlet sessions, ...)
  • UI Action execution stats
    • Collect calls to `info.magnolia.ui.api.action.AbstractActionExecutor#execute` (Micrometer)?
    • Investigate Vaadin 8 debug logs on request handling (effectively we'd be interested in UIDL request handler, that would cover all UIDL/AJAX requests though, including data fetching from Grids, not only UI actions)

Discovery notes

• We cannot collect counts (of pages, assets, items in workspaces etc.) via JCR queries. These do not support aggregation functions. We could query for the items and just count them, which might create too much load for big result sets.
• We could determine frequency and paths of publications from logs, not the sizes though as these are not logged.
• DX Core exposes a Dropwizard metrics registry (MicrometerRegistryProvider), which we can use to collect and expose the above metrics. The registry is currently bound to JMX where it can be scraped from by monitoring tools.
• Number of JCR sessions is exposed via the info.magnolia.stats.JCRStats MBean.
• Jackrabbit itself does not register any MBeans. However it provides the following helpers that still needs JMX bindings from the use site:

• • One org.apache.jackrabbit.api.jmx.EventListenerMBean per observation listener with statistics about observation events.
  • The org.apache.jackrabbit.api.jmx.QueryStatManagerMBean exposing information about query and its performance.
  • org.apache.jackrabbit.api.stats.RepositoryStatistics exposing a wealth of information about repository read, write and cache performance.