Open jimrobinson opened 4 years ago
If you want more precision, then use -r, --reps=NUM
with -t, --time=NUM a signal is fired when the timer expires but if a thread is in a system call, it won't respond until after it completes.
On Tue, Jun 2, 2020 at 10:59 AM James A. Robinson notifications@github.com wrote:
I've never seen siege do this before (and I've been running it a lot lately), but I thought it was interesting that it apparently is possible for siege to keep going after its -t
has been reached: $ ps -ef | grep [s]iege jimr 14315 14097 0 07:24 pts/0 00:00:00 docker run --name jimr_siege --rm -it -v /home/jimr:/data jimrobinson/bombard:latest siege -q -f /data/1300.urls.txt -b -t 10m jimr 14352 14334 99 07:24 pts/0 00:57:33 siege -q -f /data/1300.urls.txt -b -t 10m $ date Tue 2 Jun 07:45:16 PDT 2020
This was siege 4.0.5 running inside a ubuntu:16.04 docker container (built using https://github.com/jimrobinson/bombard, available via https://hub.docker.com/jimrobinson/bombard)
I eventually used docker stop on the job and it spat the following out before exiting:
[error] Address resolution failed at sock.c:158 with the following error:: No such file or directory [error] Name or service not known: No such file or directory [error] Address resolution failed at sock.c:158 with the following error:: No such file or directory [error] Name or service not known: No such file or directory
As far as I can determine it wasn't running out of sockets (netstat -nt wasn't showing a lot of TIME_LIMIT files).
The siege configuration is mostly the default, the differences being
turning off show-logfile, disabling json_output, and specifying a default logfile and file.
verbose = true color = on quiet = false json_output = false show-logfile = false logging = false logfile = /data/siege.log gmethod = HEAD parser = true nofollow = ad.doubleclick.net nofollow = pagead2.googlesyndication.com nofollow = ads.pubsqrd.com nofollow = ib.adnxs.com limit = 255 protocol = HTTP/1.1 chunked = true cache = false connection = close concurrent = 25 file = /data/urls.txt delay = 0.0 internet = false benchmark = false accept-encoding = gzip, deflate url-escaping = true unique = true
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JoeDog/siege/issues/178, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJRHZXZHZ6MIW67YD4ROELRUUHWHANCNFSM4NQZZAVQ .
Thanks, a missed signal would explain it.
I've never seen siege do this before (and I've been running it a lot lately), but I thought it was interesting that it apparently is possible for siege to keep going after its
-t <limit>
has been reached:This was siege 4.0.5 running inside a ubuntu:16.04 docker container (built using https://github.com/jimrobinson/bombard, available via https://hub.docker.com/jimrobinson/bombard)
I eventually used
docker stop
on the job and it spat the following out before exiting:As far as I can determine it wasn't running out of sockets (netstat -nt wasn't showing a lot of TIME_LIMIT files).
The siege configuration is mostly the default, the differences being
turning off show-logfile, disabling json_output, and specifying a default logfile and file.