Setting: journalFlushWhenQueueEmpty=true journalMaxGroupWaitMSec=0 brings things mostly back to normal. The bookie bench did eventually finish with the default, it just took 20 minutes.
So the only thing outstanding for this release is the JNA license. If you roll a new release with that (or drop the bin packages), I'll give my +1 for the release. -Ivan Sijie Guo writes: > On Mon, Oct 6, 2014 at 9:06 AM, Ivan Kelly <[email protected]> wrote: > >> I've downloaded, built and tested the src release. It looks fine. >> >> The -bin releases contain jna.jar, which isn't mentioned in the NOTICE >> file, so -1 for releasing the binary tarballs. You can still release the >> source, just leave out the binaries. I think this is ok, since 4.3.0 >> isn't GA. >> >> I ran a few benchmarks to compare against 4.2.2. The bookie benchmark >> didn't run for 4.3.0. It just hangs on "Benchmarking latency". For a >> single ledger on 3 bookies, performance is acceptable, but latency is >> higher. For 1000 ledgers on 3 bookies, tpt and latency is much better, >> but tpt is very variable. I did see a lot of timeouts in some runs >> also. >> >> single ledger, 3 bookies >> | 4.2.2 | | 4.3.0 | >> | tpt | lat p99 | lat p95 | | tpt | lat p99 | lat p95 | >> | 9995 | 87.98 | 77.26 | | 9988 | 132 | 117 | >> | 9997 | 97.55 | 80.70 | | 9991 | 111 | 107 | >> | 9996 | 105.80 | 86.20 | | 9989 | 103 | 100 | >> >> 1000 ledgers, 3 bookies >> | 4.2.2 | | 4.3.0 | >> | tpt | lat p99 | lat p95 | | tpt | lat p99 | lat p95 | >> | 14588 | 668 | 662 | | 23728 | 229 | 219 | >> | 13571 | 701 | 649 | | 39417 | 230 | 219 | >> | 14062 | 697 | 688 | | 40654 | 231 | 222 | >> | | | | | | | | >> > > You should tune the journal settings before you run the benchmark. > > the default value for 'journalMaxGroupWaitMSec' is 200, which is used for > high throughput traffic rather than latency-sensitive traffic. you could > reduce it to 6~10 millis, if you are going to gain better latency. > > in general, if you want to compare with 4.2.2, please set > 'journalFlushWhenQueueEmpty' to true, so it would kind of disabling > time-based group committing. > > >> >> Overall, I'm not sure this release is fit to go without having -alpha or >> -beta attached to its version, to make it clear that it shouldn't be >> used as is in production. > > > I don't think we need to use -alpha or -beta. If we think this release > isn't stable enough, we don't need to switch the stable to 4.3.0. so 4.3.0 > is still the latest but not the stable one, while 4.2.* is the stable one. > > >> In particular I'm worried about the bookie >> benchmark not working [1], and the variability of the 1000 ledger >> benchmark. The latency increase for a single ledger can be attributed to >> the added batching in the journal. >> > > Please re-run your benchmark with the suggested configuration settings. > > >> >> -Ivan >> >> [1] bookkeeper-benchmark/bin/benchmark bookie -zookeeper <zk> -host >> <bookie> >> >> >>
