Hi guys,
----- Original Message -----
>
> fche wrote:
> > [...]
> > An ideal outcome would have been 1 task_t matching just that
> > final block - one pmFetch PDU, one sample on the server side,
> > one timestamp, and one result logged.
>
> Right. One way to do this would be to have the parser generate one
> task_t per "(permission,time)" tuple rather than build duplicates
> per config-language { } group. Then as we parse metrics, they'd get
> dropped into the one-or-few distinct task_t's, duplicate-eliminated
> as we go, and optfetched then or once at the end.
*nod* - this was the direction that earlier patch was starting to
head, and which the attached patch now has almost completed (tests
061 and 087 are not yet playing ball, but that'll have to be a job
for tomorrow).
> kenj wrote:
> [...]
> OK and good luck with optfetch .. we know who wrote that code, and let
> me only say that optfetch was the warm-up exercise before the interp.c
> main game!
Hah!
> One thing you'll have to watch in the pmlogger change is that the -r
> option will no longer work ... this very useful option reports archive
> size projections based on the config block and does not enumerate all
> the metrics in the block in the report ... you'll need to change this to
> report per task_t and list all metrics in the pmFetch (as the rationale
> here is to be able to tune the config file if the archives are becoming
> too large) ... if you get too aggressive with rolling config blocks into
> a small number of task_t's this won't be possible, or the report will
> have to be per metric (which may be a better idea anyway). Probably
> needs some sleep and think time on this, rather than design on the fly.
So far I've gone with the same scheme Frank introduced, which is to stick
with the task_t's but now display all metrics within each (non ellipsis-
shortened variant). It will behave slightly differently since task_t's
are now a little more optimal, but it seems readable to me & easy to nut
out what's being logged at what rate, what sizes to expect, etc.
If you have time, please review the attached patch. It applies to a tree
with commits 764a143d & e2301eb9 reverted (keeping 87fb3a93, as discussed
above); it also contains test 726 exercising that task_t rearrangement is
happening in the way we're after. It does not tackle the one other
optimisation Frank suggested (looking for blocks with intervals that are
multiples of another) - that can be an exercise for the reader. ;)
So far so good anyway - if those last couple of failures are nothing too
terrible and nothing falls out of review, I'll go ahead and push this in
(hopefully tomorrow).
cheers.
--
Nathan
revised-pmlogger-task-optimisation.patch
Description: Text Data
|