David,
I would say remove the caveat.Thanks for offering.
Charlie
On Fri, Jan 10, 2020 at 1:55 PM Dave Barnes wrote:
> Sounds like the caveat could be dropped from the user guide. If we have
> consensus on that (am I understanding correctly?), I'll initiate a JIRA
> ticket.
>
> On Fri, Jan
Read that as “As of geode 1.9.0 …”.
Anthony
> On Jan 10, 2020, at 1:19 PM, Jacob Barrett wrote:
>
> The biggest impact was in recording all the additional stats in the old
> blocking stats implementation. As of 9.8 the stats internals are mostly
> non-blocking. Enabling time stats has very li
Sounds like the caveat could be dropped from the user guide. If we have
consensus on that (am I understanding correctly?), I'll initiate a JIRA
ticket.
On Fri, Jan 10, 2020 at 1:47 PM Jacob Barrett wrote:
> The biggest impact was in recording all the additional stats in the old
> blocking stats
The biggest impact was in recording all the additional stats in the old
blocking stats implementation. As of 9.8 the stats internals are mostly
non-blocking. Enabling time stats has very little of any impact now.
> On Jan 10, 2020, at 12:45 PM, Dan Smith wrote:
>
> I personally wouldn't be to
When we were doing Micrometer work we confirmed that enable-time-statistics
doesn't change performance. We'd like to deprecate this property and turn
it on always.
On Fri, Jan 10, 2020 at 12:45 PM Dan Smith wrote:
> I personally wouldn't be too worried about enabling time based statistics
> in p
I personally wouldn't be too worried about enabling time based statistics
in production. I think we segregated the time statistics because they do
have to call System.nanoTime to measure the elapsed time. At one point in
the history with old JDKs they called System.currentTimeMillis, which was
real
