On Tue, 15 Jun 2021 10:05:29 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
> Hello Michaël,
>
> >> I think we don't have to call doLog() before logAgg(). If we call doLog(),
> >> we will count an extra transaction that is not actually processed because
> >> accumStats() is called in this.
> >
> > Yes, calling both is weird.
>
> The motivation to call doLog is to catch up zeros on slow rates, so as to
> avoid holes in the log, including at the end of the run. This "trick" was
> already used by the code. I agree that it would record a non existant
> transaction, which is not desirable. I wanted to avoid a special
> parameter, but this seems unrealistic.
>
> > Is using logAgg() directly in the context actually right when it comes
> > to sample_rate?
>
> The point is just to trigger the last display, which is not triggered by
> the previous I think because of the precision: the start of the run is
> not exactly the start of the thread.
>
> > We may not log anything on HEAD if sample_rate is enabled, but we would
> > finish by logging something all the time with this patch.
>
> I do not get it.
It was not a problem because --sampling-rate --aggregate-interval cannot be
used at the same time.
> > If I am following this code correctly, we don't care about accumStats()
> > in the code path of a thread we are done with, right?
>
> Yes.
>
> Attached a v3 which adds a boolean to distinguish recording vs flushing.
Sorry, but I can't find any patach attached...
--
Yugo NAGATA <nagata@sraoss.co.jp>
