[wildfly-dev] Configuration of statistics gathering

[Brian Stansberry]

On 12/12/13 12:03 PM, Jesper Pedersen wrote:
> On 12/12/2013 12:38 PM, Brian Stansberry wrote:

>> 4) My intent is to make the default values for these attributes be
>> "false". I won't change any default though unless the relative compoent
>> lead has indicated agreement in this thread or elsewhere.
>>
>> But, if you disagree with "false" as the default, please let's use this
>> thread to sort that out, get input from the performance team, etc, so we
>> can have at least a clear understanding of why some uses have 'true'.
>>
>
> IronJacamar uses statistics internally in order to display run-time
> information of the pools.
>
> IronJacamar 1.1.2+ has a change which will allow to turn-off statistics,
> but that results in nothing is displayed to the users in that case.
>
> If we turn-off statistics by default we will have to be careful on what
> to communicate to the users, since they will expect see basic
> information out of the box. Maybe IronJacamar can display more
> information than the core pool settings, but requires further investigation.
>
> I think in order to turn it off we need proof that there is a huge
> benefit for standard work loads. In the end we are talking about an
> extra section in the guide that explains turning off statistics will
> increase performance. Nothing new there. Or ship a "performance" profile.
>
> Just so we are on the same page, the IronJacamar statistics is done by 2
> x System.currentTimeMillis() + a call to Atomic(Long|Integer|...) - let
> the flame war begin :) As always, patches welcome.
>
>> Jesper, ^^^. ;-)
>>
>
> Why do you single me out, dude ;)
>

You're the guy who argued for 'true'!

>>
>> That's for WF 8. For the next release I recommend that we also create
>> subsystem-level attributes to hold the default value for the several
>> cases where this setting is only configurable on a per-deployment level.
>> An example would be the jpa subsystem could have a statistics-enabled
>> attribute that drives the setting for all persistence units unless the
>> PU descriptor overrides or the admin overrides using the existing
>> per-deployment attribute. Besides being an aid to usability, having an
>> attribute that ends up in the persistent configuration will also help
>> deal with issues where, for example, the desired default for WildFly is
>> different than the desired default for some future EAP release. The
>> standard configs for the EAP release can just use a different value.
>>
>>
>
> Sounds good, although having it as an option in each deployment
> descriptor for each component type maybe overkill. I think an option in
> wildfly.xml would be enough, and then override through
> statistics-enabled via CLI.
>

My previous post wasn't meant to propose making this configurable in 
deployment descriptors (although maybe that's a good idea; I haven't 
really thought about it.)  I mentioned the PU descriptor just because I 
was using JPA as an example and IIRC config in the DD is part of that 
particular example. Hibernate lets the user enable/disable statistics 
via a property in persistence.xml.


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat