Unless server admins are manually editing the underlying data stores, the plugin is pretty much in full control of all data going in and out. This means that the plugin could support a very crude caching mechanism where stats are cached on reads and blanket evicted on writes. Different invalidation strategies could be employed to further reduce any performance impact.
The plugin actually currently has a CachingStatsStore decorator implementation, but it is "dead code" that is never employed. It might be a good starting point to simply introduce a cache: true/false config option and wrap whatever StatsStore is instantiated in a CachingStatsStore during plugin load.
Unless server admins are manually editing the underlying data stores, the plugin is pretty much in full control of all data going in and out. This means that the plugin could support a very crude caching mechanism where stats are cached on reads and blanket evicted on writes. Different invalidation strategies could be employed to further reduce any performance impact.
The plugin actually currently has a
CachingStatsStoredecorator implementation, but it is "dead code" that is never employed. It might be a good starting point to simply introduce acache: true/falseconfig option and wrap whatever StatsStore is instantiated in a CachingStatsStore during plugin load.