latest v4.1.5 siege aborted due to excessive socket failure

[dylan2intel]

root@wie:/# siege --version
SIEGE 4.1.5

Copyright (C) 2022 by Jeffrey Fulmer, et al.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.

root@wie:/# cat ~/.siege/siege.conf |grep -v '^#' |sed '/^$/d'
verbose = false
color = on
quiet = false
json_output = false
show-logfile = true
logging = false
gmethod = HEAD
parser = false
nofollow = ad.doubleclick.net
nofollow = pagead2.googlesyndication.com
nofollow = ads.pubsqrd.com
nofollow = ib.adnxs.com
limit = 1024
protocol = HTTP/1.1
chunked = true
cache = false
connection = close
concurrent = 25
delay = 0.0
internet = false
benchmark = false
accept-encoding = gzip, deflate
url-escaping = true
unique = true

It works if I run siege on my local virtual machine
However, switch to run on a higher performance server, it failed with below message
I am running a benchmark test against wordpress site with nginx as reverse proxy and php-fpm as backend.

root@wie:/# /run_siege.sh
Disable verbose and logging...
CLIENT_SIEGE_RUN_MODE: duration
timeout -k 180s -s INT 120s siege -c 100 -t 60s -b -f /WordpressTarget.urls 2>&1
Opcode cache enabled, warm up...

begin_region_of_interest
** SIEGE 4.1.5
** Preparing 100 concurrent users for battle.
The server is now under siege...siege aborted due to excessive socket failure; you
can change the failure threshold in $HOME/.siegerc

Transactions: 848 hits
Availability: 43.92 %
Elapsed time: 3.57 secs
Data transferred: 43.62 MB
Response time: 0.18 secs
Transaction rate: 237.54 trans/sec
Throughput: 12.22 MB/sec
Concurrency: 42.64
Successful transactions: 824
Failed transactions: 1083
Longest transaction: 3.16
Shortest transaction: 0.00

end_region_of_interest
root@wie:/# grep failure ~/.siege/siege.conf

Failures: This is the number of total connection failures allowed

before siege aborts. Connection failures (timeouts, socket failures,

ex: failures = 50

failures =

Btw, I can workaround the issue with change limit and failure in ~/.siege/siege.conf

sed -i "
s|^limit = 255|limit = $CLIENT_SIEGE_CFG_LIMIT|;
s|^parser = true|parser = false|;
s|^# failures =|failures = $CLIENT_SIEGE_CFG_FAILURE|;
" "$SIEGE_CONF"

However, does the workaround make sense?

[JoeDog]

This tells me that your web server can't handle 100 concurrent users. Behind the listener, your web server has a pool of handlers. That pool should be set to at least 100. If it is, then what's probably happening is that transactions take too long, requests back up, then sockets start timing out. Step up the number of simulated users slowly to see what you can handle.

…

On Sun, Sep 25, 2022 at 6:10 AM Chen, Dylan ***@***.***> wrote: ***@***.***:/# siege --version SIEGE 4.1.5 Copyright (C) 2022 by Jeffrey Fulmer, et al. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ***@***.***:/# cat ~/.siege/siege.conf |grep -v '^#' |sed '/^$/d' verbose = false color = on quiet = false json_output = false show-logfile = true logging = false gmethod = HEAD parser = false nofollow = ad.doubleclick.net nofollow = pagead2.googlesyndication.com nofollow = ads.pubsqrd.com nofollow = ib.adnxs.com limit = 1024 protocol = HTTP/1.1 chunked = true cache = false connection = close concurrent = 25 delay = 0.0 internet = false benchmark = false accept-encoding = gzip, deflate url-escaping = true unique = true It works if I run siege on my local virtual machine However, switch to run on a higher performance server, it failed with below message I am running a benchmark test against wordpress site with nginx as reverse proxy and php-fpm as backend. ***@***.***:/# /run_siege.sh Disable verbose and logging... CLIENT_SIEGE_RUN_MODE: duration timeout -k 180s -s INT 120s siege -c 100 -t 60s -b -f /WordpressTarget.urls 2>&1 Opcode cache enabled, warm up... begin_region_of_interest ** SIEGE 4.1.5 ** Preparing 100 concurrent users for battle. The server is now under siege...siege aborted due to excessive socket failure; you can change the failure threshold in $HOME/.siegerc Transactions: 848 hits Availability: 43.92 % Elapsed time: 3.57 secs Data transferred: 43.62 MB Response time: 0.18 secs Transaction rate: 237.54 trans/sec Throughput: 12.22 MB/sec Concurrency: 42.64 Successful transactions: 824 Failed transactions: 1083 Longest transaction: 3.16 Shortest transaction: 0.00 end_region_of_interest ***@***.***:/# grep failure ~/.siege/siege.conf Failures: This is the number of total connection failures allowed before siege aborts. Connection failures (timeouts, socket failures, ex: failures = 50 failures = Btw, I can workaround the issue with change limit and failure in ~/.siege/siege.conf sed -i " s|^limit = 255|limit = $CLIENT_SIEGE_CFG_LIMIT|; s|^parser = true|parser = false|; s|^# failures =|failures = $CLIENT_SIEGE_CFG_FAILURE|; " "$SIEGE_CONF" However, does the workaround make sense? — Reply to this email directly, view it on GitHub <#212>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJRHZVOGSFNPVHXLTRJ4UTWAAQJHANCNFSM6AAAAAAQVA2IXE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Jeff Fulmer 1-717-799-8226 https://www.joedog.org/ He codes