Hi Frederic,
Op 1-10-2018 om 15:15 schreef Frederic Lecaille:
On 09/15/2018 02:03 AM, PiBa-NL wrote:
Hi List, Willy,
Hi Pieter,
Sorry for this late reply.
I am also sorry to tell you that -D option should not be used anymore
because it as been recently broken. It adds an extra 2s delay on my PC.
There is a 'newer' version of the regtest in one of the other mails (
https://www.mail-archive.com/[email protected]/msg31318.html ). it
only runs 4x10 connections. and doesn't use -D anymore and well
discussing with Willy some odd behavioral differences between his and my
test results..
Without this option, on my PC the test fails but after having being
run during about 300ms due to the regex which does not match.
CummConns (resp. CumReq) never reaches 3001 (resp. 3002).
Note that as this script is highly verbose it may be required to
increase the varnishtest internal buffer size (see -b varnishtest
option).
Thanks didn't realize that one could have helped, probably not needed
anymore with the changed regtest though.
I've created a regtest that checks that when concurrent connections
are being handled that the connection counters are kept properly.
I think it could be committed as attached. It takes a few seconds to
run. It currently fails on 1.9-dev2 (also fails on 1.8.13 with kqueue
on FreeBSD, adding a 'nokqueue' on 1.8.13 makes it succeed though..).
I think it might be a good and reproducible test to run.?
Or does it need more tweaking? Thoughts appreciated :).
I have shorten the "haproxy -cli" section like that:
haproxy h1 -cli {
send "show info"
expect ~ "CumConns: 3001*\\nCumReq: 3002*"
} -wait
Thats a nice one, i did try a .* regex like wildcard check but found
that didn't work, this will certainly help in case the test fails to
produce less repeated/unneeded output and when it doesn't fail it will
be a bit faster i guess, and allow for more checks on the same set of
stats to take place with little effort.
Note that all the Slg_1 syslog specs are not completely run because
you do not wait for its termination with "syslog Slg_1 -wait" command
this is why it does not fails (but it should: the syslog server does
not receive 15 messages).
I didn't intent to check for 15 messages as a valid outcome, but was
looking more for 'some' syslog output when the testcase fails for some
reason.. With the now fairly limited 40 connections it might be feasible
to more properly check syslog output though. With 3000 connections it
wasn't really nice when syslog was writing everything to the screen. Ill
take another look at that one.
Regards,
PiBa-NL (Pieter)
