Description of problem: We see the Infinispan statistics as a hotspot when profiling for performance. Version-Release number of selected component (if applicable): How reproducible: All the time. Steps to Reproduce: 1. 2. 3. Actual results: Throughput suffers because of the statistics. Expected results: Be able to turn statistics off through the subsystem configuration. Additional info:
Paul Ferraro <paul.ferraro> made a comment on jira WFLY-2415 PR will disable statistics by default and adds a configuration option to enable them per cache and cache-container.
Merged and acked on QA's behalf. This is for a RFE: https://issues.jboss.org/browse/EAP6-76
It seems that per cache setting is not currently possible, this is what was tested: I had a server instance with an application deployed and no changes to standalone-ha.xml (server started with this profile). Connecting to the server with jconsole showed that statistics are correctly not taken by default. (thus, value "undefined" for statistics-enabled behaves as "false", that's correct) Changing the standalone-ha.xml or modifying the settings through cli had these outcomes (web container, repl cache for example): cache-container cache outcome ---------------|-----|------- false true the cache that had statistics-enabled set to true still didn't collect any statistics false false no cache collected any statistics, correct true true statistics were collected for all caches of the given cache container true false statistics were collected for all caches of the given cache container regardless of per cache setting Thus, I couln't enable collecting statistics per cache. When reading attributes through jboss-cli it always shows the correct values (true/false/undefined for cache/cache-container), it seems that setting per cache is not propagated to mbeans though. When connecting to the server with jconsole and looking at the mbeans, their settings only reflects the setting of a cache-container. Btw, this is also how Wildfly 8.0.0.Final behaves.
I have verified that the setting is sucessfully applied to org.infinispan.configuration.cache.JMXStatisticsConfigurationBuilder hinting at a possible Infinispan bug.
I did this: - start wildfly - start JBoss CLI - start JConsole and look at MBeans for cache managers and caches -- check if cache manager stats are enabled by checking CacheManager MBean attribute global configuration as property string -- check if cache stats are enabled by checking Statistics MBean attribute statisticsEnabled If found these combinations in the managenment CLI produced the correct results in the corresponding MBeans: - cache-container=false, cache=false - cache-container=true, cache=true and these combinations did not: - cache-container=false, cache=true - cache-container=true, cache=false This same stat of affairs happens whether we use a :reload from the CLI or we use a reboot of the server from the command line between changes to the management attributes.
It's a Wildfly problem: see https://issues.jboss.org/browse/WFLY-3106
Looks good now. The cache/cache-manager combinations mentioned above now work correctly. There is one thing though - "undefined" state is now entirely equivalent to "false". ("undefined" = <cache-container name="a" ... > , "false" = <cache-container name="a" ... statistics-enabled="false">) What that means is that you won't be able to enable statistics for any caches only by setting cache-manager to statistics-enabled="true" because you'll still have to explicitly set statistics-enabled to "true" for the caches. Cache manager setting still enables some other statistics, so it's functionality isn't reduced to zero. This seems a little unintuitive to me, but since I don't know of any official documentation and I can enable statistics for any subset of caches, I'll verify it. (I'd expect "undefined" setting for cache to be overridden by "true" setting for cache manager but behave as "false" otherwise.) Summary: VERIFIED. Is there a documentation that explains how exactly this should behave?
Documentation: this is a customer drive feature request that we implemented. This should be documented so that customers know about it and can leverage this new option. If anyway wants to document this further, see [1] where I explained what are the combinations and which take precedence in terms of cache container and cache settings. [1] https://issues.jboss.org/browse/WFLY-3377?focusedCommentId=12969081&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12969081
Modified the release notes text per comment in bug 1123334.