]> granicus.if.org Git - libevent/commit
Simplify bufferevent timeout tests to reduce CPU usage in between start/compare
authorAzat Khuzhin <a3at.mail@gmail.com>
Sun, 21 Oct 2018 15:31:01 +0000 (18:31 +0300)
committerAzat Khuzhin <a3at.mail@gmail.com>
Sun, 21 Oct 2018 21:53:07 +0000 (00:53 +0300)
commit6ac8e775bb3cba49c276c90e288554635d38b466
treec649725bafac614c42fe0cb8117170485da874fb
parent3e6553a1808989c15b8dd1945b4707b7d35667ad
Simplify bufferevent timeout tests to reduce CPU usage in between start/compare

Between start (setting "started_at") and comparing the time when
timeouts triggered with the start (test_timeval_diff_eq), there is too
much various things that can introduce extra delays and eventually could
fail the test on machine with shortage of CPU.

And this is exactly what happend on:
- travis-ci
- #262

Here is a simple reproducer that I came up with for this issue:
  docker run --cpus=0.01 -e LD_LIBRARY_PATH=$PWD/lib -e PATH=/usr/bin:/bin:$PWD/bin -v $PWD:$PWD --rm -it debian:testing regress --no-fork --verbose bufferevent/bufferevent_timeout

Under limited CPU (see reproducer) the test almost always has problems
with that "write_timeout_at" exceed default timeval diff tolerance
(test_timeval_diff_eq() has 50 tolerance), i.e.:
  FAIL ../test/regress_bufferevent.c:1040: assert(labs(timeval_msec_diff(((&started_at)), ((&res1.write_timeout_at))) - (100)) <= 50): 101 vs 50

But under some setup write timeout can even not triggered, and the
reason for this is that we write to the bufferevent 1024*1024 bytes, and
hence if evbuffer_write_iovec() will has some delay after writev() and
not send more then one vector at a time [1], it is pretty simple to
trigger, i.e.:
  FAIL ../test/regress_bufferevent.c:1040: assert(labs(timeval_msec_diff(((&started_at)), ((&res1.write_timeout_at))) - (100)) <= 50): 1540155888478 vs 50

  [1]: https://gist.github.com/azat/b72773dfe7549fed865d439e03de05c1

So this patch just send static small payload for all cases (plus a few
more asserts added).

The outcome of this patch is that all regression tests passed on
travis-ci for linux box [2]. While before it fails almost always [3].
Also reproducer with CPU limiting via docker also survive some
iterations (and strictly speaking it should has less CPU then travis-ci
workers I guess).

  [2]: https://travis-ci.org/azat/libevent/builds/444391481
  [3]: https://travis-ci.org/libevent/libevent/builds/444336505
test/regress_bufferevent.c