JoeDog
commented
1 year ago 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 https://github.com/JoeDog/siege/issues/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
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?