[wildfly-dev] Configuration of statistics gathering

[Andrig Miller]

----- Original Message -----
> From: "Jesper Pedersen" <jesper.pedersen at jboss.org>
> To: wildfly-dev at lists.jboss.org
> Sent: Thursday, December 12, 2013 11:03:54 AM
> Subject: Re: [wildfly-dev] Configuration of statistics gathering
> 
> On 12/12/2013 12:38 PM, Brian Stansberry wrote:
> > 1) For all resources that currently expose an attribute to
> > enable/disable statistics, I'll add an attribute that will be named
> > "statistics-enabled". Why that?
> >
> > a) it's an attribute, so it's name should reflect a state, not an
> > action
> > like, for example, "enable-statistics"
> 
> Ok with that.
> 
> > b) simply using "statistics" is shorter, but in some places that
> > key is
> > used as a child type (e.g. statistics=pool) and a resource can't
> > have a
> > child type and an attribute with the same name.
> >
> 
> Yeah, lets not change this.
> 
> > 2) For compatibility, the existing attribute will be retained as an
> > alias to the new one. I'll add deprecation metadata. I'll also set
> > up
> > the appropriate transformation stuff for mixed domain usage.
> >
> 
> Ok.
> 
> > 3) Any new stuff people do (e.g. [1], [2]), please use
> > "statistics-enabled".
> >
> 
> Agreed.
> 
> > 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.
> 

There is nothing special about the workload that drove this change, in terms of how its using IJ.  So, the change benefits any application that uses a data source.

I'm not really sure why any additional proof is required.  If somehow the workload was special in some way, then I could see that, but its not.  Its an EE 5 based application using EJB 3 entities with container managed persistence mapped to data sources.

By definition, if that application improves its response times signficantly, which it did, then any application will experience similar results as its scaled.  You probably wouldn't be able to measure it on an application with one user, but as you scale up the user count, and concurrency increases, the larger the impact.

Andy

> 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 ;)
> 
> >
> > 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.
> 
> Best regards,
>   Jesper
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>