On Sat, 11 Apr 2020 19:16:54 +0200 Lukas Straub <lukasstra...@web.de> wrote:
> Hello Everyone, > I did some Benchmarking with iperf3 and memtester (to dirty some guest memory) > of colo performance in qemu 4.2.0 and in qemu 5.0.0-rc2 > with my bugfixes on top.( > https://lists.nongnu.org/archive/html/qemu-devel/2020-04/msg01432.html ) > > I have taken the average over 4 runs. > Client-to-server tcp bandwidth rose slightly from ~83.98 Mbit/s to ~89.40 > Mbits. > Server-to-client tcp bandwidth fell from ~9.73 Mbit/s to ~1.79 Mbit/s. > Client-to-server udp bandwidth stayed the same at 1.05 Mbit/s > and jitter rose from ~5.12 ms to ~10.77 ms. > Server-to-client udp bandwidth fell from ~380.5 Kbit/s to ~33.6 Kbit/s > and jitter rose from ~41.74 ms to ~83976.15 ms (!). > > I haven't looked closely into it, but i think > 0393031a16735835a441b6d6e0495a1bd14adb90 "COLO: Optimize memory back-up > process" > is the culprint as it reduces vm downtime for the checkpoints but increases > the overall checkpoint time and we can only release miscompared primary > packets > after the checkpoint is completely finished. > > Another thing that I noticed: With 4.2.0, the secondary qemu uses thrice > the amount of gest memory. With 5.0.0-rc2 it's just double the amount of > guest memory. So maybe the ram cache isn't working properly? > > Regards, > Lukas Straub Hmm, I looked at my test again and saw that the results where very noisy, so qemu 5.0.0-rc2 being slower was just a coincidence. I did increase the test time and the results are more meaningful now. Now qemu 5.0.0-rc2 is around the same speed and still faster in the client-to-server tcp case. Sorry for the noise. Regards, Lukas Straub
pgp6dUmlTa8z_.pgp
Description: OpenPGP digital signature