> I'm not sure I like the idea of printing a percentage. It might be
> unclear what the denominator was if somebody feels the urge to work
> back to the actual number of skipped transactions. I mean, I guess
> it's probably just the value you passed to -R, so maybe that's easy
> enough, but then why bother dividing in the first place? The user can
> do that easily enough if they want the data that way.
Indeed "skipped" and "late" per second may have an unclear denominator. If
you divide by the time, the unit would be "tps", but 120 tps performance
including 20 late tps, plus 10 skipped tps... I do not think it is that
clear. Reporting "tps" for transaction *not* performed looks strange.
Maybe late transactions could be given as a percentage of all processed
transactions in the interval. But for skipped the percentage of what? The
only number that would make sense is the total number of transactions
schedule in the interval, but that would mean that the denominator for
late would be different than the denominator for skipped, which is
basically uncomprehensible.
> I agree with you that it would be good to get some statistics on
> late/skipped transactions, but it's not obvious what people will want.
> Late transactions, straight up? Late by more than a threshold value?
Yes.
Under throttling transaction are given a schedule start time. When the
transactions can actually start:
(1) if it is already more late (before even starting) than the latency limit (a threshold), it is *NOT* started,
butcounted "skipped"
(2) otherwise it is started. When it finishes, it may be (2a) out of the latency limit (scheduled time + limit)
=> it is counted as "late" (2b) within the latency limit => all is well
--
Fabien.
