joedog / siege Goto Github PK
View Code? Open in Web Editor NEWSiege is an http load tester and benchmarking utility
License: GNU General Public License v3.0
siege's People
Contributors
Stargazers
Watchers
Forkers
ezc smj10j seanchen spectrumjade daniel-ccx gigabo nigelzor benferrer darshandeshmukh11 codedebug tan14 jasonschuman yeahgoodboy wbc91 hubspot r-singh andyzhuangyy songguang-2010 hbf phillip2019 adaminfinitum akshatthakar stamf walac snapdealrohit mailtoharshgupta anders007 apeschel ilyakalinin microlin neotronic endrjuskr flygoast awinlei nask0 linearregression simudream airfer velocitystorm mckellyln ghosthamlet zeb209 crudbug noscripter daemonna ksmaheshkumar xevix iamazhi matrixbirds awebdev therebelrobot catwarrior nluchs mattludwigs vfilanovsky rossad rajmannartech wyoung dcharkes alexzxela isemantics richardmax smartree wyatt88 florije1988 delkyd danbst antonblanchard christian-blades-cb mgsmith1000 wuvist cuulee perf-suite dragon9783 ggh666 lxh023 ashier rubyli000 jekshmek mausvargas duanshuaimin ashang thedanielk qict777 lavenresearch egweeks alexshaoyun great90 sunzhijie jonasporto matthewquinn kayess wensincai zhongxiankui zhuomingliang brajeshprashant chrisbaldauf bloodc0r3 litespeedtech liupcsiege's Issues
Improve robustness of __parse_time()
While fixing the bugs in the pull request I just sent, I came across several other weaknesses that I thought I'd at least raise for documentation reasons, if nothing else:
-
Prior to my patch, it only worked if the server returned cookie expiration times in the same time zone as the machine running Siege. My patch allows the server to return times in GMT/UTC as well and still do the right thing. But, this means you can't do a Siege across time zones unless the server uses GMT/UTC. To fix this, it will have to parse the TZ part of the date string and work out the correct offsets.
-
The parser claims in its comments to handle 2-digit dates, but it doesn't. It'll blindly subtract 1900 from "93" for example.
-
It's blindly skipping over the delimiter values allowed in RFC 6265. The sanity checks around the mktime() call partially compensate for this, but I could imagine hand-crafting bogus date strings that it would nevertheless accept. I think I could even do the reverse: send a string that's legal according to the RFC but which it wouldn't accept.
A series of regexes might suffice. If not, RFC 6265 gives you the grammar for yacc or similar.
Unbundle joedog
Distributions don't like if packages are bundling libraries for a couple of valid reasons. siege is bundling joedog and this leads to patching on the distributions-side.
Can you please consider to unbundle joedog or add an option to configure which let you use choose which installation to use?
Thanks.
Cookies in v3.0.1 repeatedly appended
This issue is resolved in v4 but I wanted to put an issue out there to document it. We were seeing cookies set by the app under test repeatedly appended until the request became too large (and HaProxy just returned 400s). To be clear, it was the same session cookie repeated many times. This would happen when either specifically setting the cookie header or not. Thanks for getting it resolved.
How to simulate POST request
$ siege --version
SIEGE 3.1.1
Copyright (C) 2015 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.
$ siege -g -c 1 -r 1 "http://127.0.0.1:80/test POST ha=1&ho=2"
POST /test POST ha=1&ho=2 HTTP/1.0
Host: 127.0.0.1:80
Accept: */*
User-Agent: Mozilla/5.0 (unknown-x86_64-linux-gnu) Siege/3.1.1
Connection: close
Content-type: application/x-www-form-urlencoded
Content-length: 9
ha=1&ho=2
HTTP/1.1 404 Not Found
Server: nginx
Date: Mon, 02 Nov 2015 07:44:34 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
[done]
Look: POST /test POST ha=1&ho=2 HTTP/1.0 ?
CSV verbose output has escape codes
When you set verbose output to CSV, it wraps the output in escape codes to colorize them. This makes consuming the CSVs programmatically a little hard than it needs to be.
E.g. .siegerc has
verbose = true
csv = true
Command is
siege -i -f siege_urls.txt -c 100 -d 1 -r 10 > siege-log-20160226-1645.txt
The log file lines look like:
ļæ½[0;34m[Sat, 2016-02-27 00:48:13] HTTP/1.1,200, 0.05, 1426,/myurlhere,798,2016-02-27 00:48:13ļæ½[0m
It would be much more convenient if they weren't wrapped in the escape codes.
siege 3.1.0-rc2 segfault
Running siege 3.1.0-rc2 causes a segfault against a server I'm testing. Reproduced in linux (in a docker FROM debian:jessie) and on OSX. It works with -c 1. Let me know how I can gather any needed info.
$ siege -b -c 25 -t60s -H 'Authorization: Basic REDACTED' "http://backup/my/50cent.png"
Segmentation fault: 11
** SIEGE 3.1.0-rc2
** Preparing 100 concurrent users for battle.
The server is now under siege...[ESC[1;33merrorESC[0m] socket: 65482752 address is unavailable.: Can't assign requested address
[ESC[1;33merrorESC[0m] socket: 55824384 address is unavailable.: Can't assign requested address
...
[ESC[1;33merrorESC[0m] socket: 38117376 address is unavailable.: Can't assign requested address
[ESC[1;32malertESC[0m] socket: polled(30) and discovered it's not ready sock.c:296: Operation timed out
How do you get pre-connection stats?
cURL allows you to specify much more specific timing categories as follows:
time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
time_total: %{time_total}\n
The result looks like this:
time_namelookup: 0.015
time_connect: 0.065
time_appconnect: 0.299
time_pretransfer: 0.299
time_redirect: 0.000
time_starttransfer: 0.913
time_total: 0.914
Is something like this possible in siege? I've been looking through http.c to see if I could figure out where to extract this information, but it's not clear to me if it's even being recorded. Any tips or information would be greatly appreciated.
Trouble building on OSX
After gettienr autoconf, automake and libtools installed...
I ran utils/bootstrap then ./configure without issue... during make, I'm getting a few warnings and an error... Here's the output (OSX Yosimite and XCode 6.4)
Making all in .
make[1]: Nothing to be done for `all-am'.
Making all in include
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive
Making all in joedog
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
Making all in lib
Making all in joedog
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c -o memory.lo memory.c
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c memory.c -fno-common -DPIC -o .libs/memory.o
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c memory.c -o memory.o >/dev/null 2>&1
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c -o notify.lo notify.c
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c notify.c -fno-common -DPIC -o .libs/notify.o
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c notify.c -o notify.o >/dev/null 2>&1
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c -o perl.lo perl.c
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c perl.c -fno-common -DPIC -o .libs/perl.o
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c perl.c -o perl.o >/dev/null 2>&1
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c -o util.lo util.c
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c util.c -fno-common -DPIC -o .libs/util.o
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c util.c -o util.o >/dev/null 2>&1
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c -o snprintf.lo snprintf.c
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c snprintf.c -fno-common -DPIC -o .libs/snprintf.o
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c snprintf.c -o snprintf.o >/dev/null 2>&1
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c -o stralloc.lo stralloc.c
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c stralloc.c -fno-common -DPIC -o .libs/stralloc.o
gcc -DHAVE_CONFIG_H -I. -I../../include -W -Wall -Wunused-value -g -O2 -c stralloc.c -o stralloc.o >/dev/null 2>&1
/bin/sh ../../libtool --tag=CC --mode=link gcc -W -Wall -Wunused-value -g -O2 -version-info 1:0:1 -o libjoedog.la memory.lo notify.lo perl.lo util.lo snprintf.lo stralloc.lo
libtool: link: warning: `-version-info/-version-number' is ignored for convenience libraries
ar cru .libs/libjoedog.a .libs/memory.o .libs/notify.o .libs/perl.o .libs/util.o .libs/snprintf.o .libs/stralloc.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libjoedog.a(snprintf.o) has no symbols
ranlib .libs/libjoedog.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libjoedog.a(snprintf.o) has no symbols
creating libjoedog.la
(cd .libs && rm -f libjoedog.la && ln -s ../libjoedog.la libjoedog.la)
make[2]: Nothing to be done for `all-am'.
Making all in src
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o array.o array.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o auth.o auth.c
auth.c:130:23: warning: unused function '__mkhash' [-Wunused-function]
private void __mkhash(const char *pass, unsigned char *nonce, unsigned char *lmresp, unsigned char *ntresp);
^
1 warning generated.
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o base64.o base64.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o client.o client.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o cookie.o cookie.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o cfg.o cfg.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o creds.o creds.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o crew.o crew.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o data.o data.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o date.o date.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o eval.o eval.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o ftp.o ftp.c
ftp.c:146:11: warning: incompatible pointer to integer conversion initializing 'size_t' (aka 'unsigned long') with an
expression of type 'pthread_t' (aka 'struct _opaque_pthread_t *') [-Wint-conversion]
size_t id = pthread_self();
^ ~~~~~~~~~~~~~~
ftp.c:236:7: warning: variable 'bytes' is uninitialized when used here [-Wuninitialized]
bytes += n;
^~~~~
ftp.c:223:13: note: initialize the variable 'bytes' to silence this warning
int bytes;
^
= 0
2 warnings generated.
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o getopt.o getopt.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o getopt1.o getopt1.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o handler.o handler.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o hash.o hash.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o http.o http.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o init.o init.c
init.c:182:54: warning: comparison of array 'my.logfile' equal to a null pointer is always false
[-Wtautological-pointer-compare]
printf("log file: %s\n", (my.logfile == NULL) ? LOG_FILE : my.logfile);
~~~^~~~~~~ ~~~~
1 warning generated.
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o load.o load.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o log.o log.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o main.o main.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o md5.o md5.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o sock.o sock.c
gcc -DHAVE_CONFIG_H -I. -I../include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -g -O2 -c -o ssl.o ssl.c
ssl.c:50:10: fatal error: 'tls1.h' file not found
#include <tls1.h>
^
1 error generated.
make[1]: *** [ssl.o] Error 1
make: *** [all-recursive] Error 1
do not round response time in verbose mode
In verbose mode, the response time values are rounded to two decimal places, i.e. 0.0078 is printed as 0.01.
We can make density plot of response time values printed by Siege
If the response time values were not rounded, then we would get the following density plot
It would be nice to instruct Siege to not round the response time values in verbose mode. This would be useful for both plotting and performance modelling. The rounding causes some problems here.
Above plots can be generated with the following R (www.r-project.org) commands
v = rexp(10 ** 5, 1 / 0.0078)
plot(density(round(v, 2))) # first plot
plot(density(v)) # second plot
Above reflects real data gathered with Siege.
Option to send Authentication automatically, instead of waiting for 401
Would be nice if HTTP Basic Authorization header were sent preemptively for all requests, to save the roundtrip after the 401. Maybe that could be an option?
# ~/.siege/siege.conf
login = user:password
Using 4.0.1, thanks.
Incorrect `content-type` header when POSTing a file
I have a url.txt file with the following:
BASEURL=http://localhost:8000
$(BASEURL)/post POST foo=bar&this=that&e=mc2
$(BASEURL)/post POST < $HOME/.siege/fixtures/test.gif
The POST with the form has the correct content-type header attached, but the .gif file, which should be sent with the content-type header of image/gif gets sent as text/plain, which then tried to render it as unicode in my log viewer. Is it possible to send non-text files via post with siege? I know it'd need to support streaming/chunking which I'm not sure if it supports. If it does support it, is it possible to turn on dynamic content-type headers for it to auto-detect, or maybe specify in the url.txt file?
Excellent tool, I'm enjoying using it so far, just some edge cases like this I'm trying to work through. Thanks!
Siege 3.1.0 segfault when verbose is true
I notice that siege (3.1.0) segfault's when you have configured concurrent users > 1 and verbose = true (both with compiled version and that one provide from repository).
If verbose is set to false, then no crash occurred even with concurrent users > 1.
Here is the backtrace:
nask0@dev-nask0 ~ $ siege -C
CURRENT SIEGE CONFIGURATION
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.125 Safari/537.36 Siege/3.1
Edit the resource file to change the settings.
version: 3.1.0
verbose: true
quiet: false
debug: false
protocol: HTTP/1.1
get method: GET
connection: close
concurrent users: 20
time to run: n/a
repetitions: 20
socket timeout: 30
accept-encoding: *
delay: 1.000 sec
internet simulation: true
benchmark mode: false
failures until abort: 1024
named URL: none
URLs file: /tmp/load-tests-urls.txt
logging: true
log file: /tmp/siege-dcr.log
resource file: /home/nask0/.siegerc
timestamped output: true
comma separated output: false
allow redirects: true
allow zero byte data: false
allow chunked encoding: true
upload unique files: true
nask0@dev-nask0 ~ $ gdb siege
GNU gdb (GDB) Fedora 7.9.1-13.fc22
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from siege...Reading symbols from /usr/lib/debug/usr/bin/siege.debug...done.
done.
(gdb) run
Starting program: /usr/bin/siege
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
** SIEGE 3.1.0
** Preparing 20 concurrent users for battle.
The server is now under siege...
[New Thread 0x7fffeb74a700 (LWP 24982)]
[New Thread 0x7fffebf4b700 (LWP 24981)]
[New Thread 0x7fffec74c700 (LWP 24980)]
[New Thread 0x7fffecf4d700 (LWP 24979)]
[New Thread 0x7fffed74e700 (LWP 24978)]
[New Thread 0x7fffedf4f700 (LWP 24977)]
[New Thread 0x7fffee750700 (LWP 24976)]
[New Thread 0x7fffeef51700 (LWP 24975)]
[New Thread 0x7fffef752700 (LWP 24974)]
[New Thread 0x7fffeff53700 (LWP 24973)]
[New Thread 0x7ffff0754700 (LWP 24972)]
[New Thread 0x7ffff0f55700 (LWP 24971)]
[New Thread 0x7ffff1756700 (LWP 24970)]
[New Thread 0x7ffff1f57700 (LWP 24969)]
[New Thread 0x7ffff2758700 (LWP 24968)]
[New Thread 0x7ffff2f59700 (LWP 24967)]
[New Thread 0x7ffff375a700 (LWP 24966)]
[New Thread 0x7ffff3f5b700 (LWP 24965)]
[New Thread 0x7ffff475c700 (LWP 24964)]
[New Thread 0x7ffff4f5d700 (LWP 24963)]
[New Thread 0x7ffff575e700 (LWP 24962)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffee750700 (LWP 24976)]
0x00007ffff6deded3 in _IO_vfprintf_internal (s=s@entry=0x7fffee73bda0, format=<optimized out>, format@entry=0x4146e0 "%s%4d: %s %d %6.2f secs: %7lu bytes ==> %-4s %s", ap=ap@entry=0x7fffee74fb80)
at vfprintf.c:1642
1642 process_string_arg (((struct printf_spec *) NULL));
(gdb) bt
#0 0x00007ffff6deded3 in _IO_vfprintf_internal (s=s@entry=0x7fffee73bda0, format=<optimized out>, format@entry=0x4146e0 "%s%4d: %s %d %6.2f secs: %7lu bytes ==> %-4s %s", ap=ap@entry=0x7fffee74fb80)
at vfprintf.c:1642
#1 0x00007ffff6eb118c in ___vsprintf_chk (s=s@entry=0x7fffee73bed0 "", flags=flags@entry=1, slen=slen@entry=40000, format=0x4146e0 "%s%4d: %s %d %6.2f secs: %7lu bytes ==> %-4s %s", args=0x7fffee74fb80,
args@entry=0x7fffee73bed0) at vsprintf_chk.c:85
#2 0x00007ffff7bd8d3e in vsprintf (__ap=0x7fffee73bed0, __fmt=<optimized out>, __s=0x7fffee73bed0 "") at /usr/include/bits/stdio2.h:46
#3 __display (color=4, fmt=<optimized out>, ap=ap@entry=0x7fffee74fb80) at notify.c:164
#4 0x00007ffff7bd8e54 in DISPLAY (color=<optimized out>, fmt=<optimized out>) at notify.c:175
#5 0x0000000000406bfa in __request (C=<optimized out>, U=<optimized out>, client=<optimized out>) at client.c:350
#6 0x00000000004071af in start_routine (client=<optimized out>) at client.c:126
#7 0x000000000040851a in crew_thread (crew=0x62c750) at crew.c:140
#8 0x00007ffff79c2555 in start_thread (arg=0x7fffee750700) at pthread_create.c:333
#9 0x00007ffff6ea1f3d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
HHVM reported Siege bugs in >2.78 ?
Hi curious if the bugs reported at http://hhvm.com/blog/9293/lockdown-results-and-hhvm-performance for Siege >2.78 been fixed in 3.1.0 yet ?
Siege ā When benchmarking frameworks we used Siege 2.78, currently all versions of Siege 3 have known problems. In particular Siege 3.0.0 to 3.0.7 send incorrect HOST headers to ports other than 80, and 443, and Siege 3.0.8 and 3.0.9 occasionally send bad paths due to incorrect redirect handling.
Concurrent Clients
Dear,
How i can set 100 concurrent client which each of them send 10000 request/connection?
Thanks
site download version out of sync with git tag release ?
Seems http://download.joedog.org/siege/siege-latest.tar.gz is 3.1.0 while latest on git is 3.1.1 https://github.com/JoeDog/siege/releases ? out of sync ?
Also any change of the git releases following a more common version naming format so insteald of 3-1-1 use 3.1.1 ?
cheers
George
Request same URL with differing headers
The workload that I'd like to use for benchmarking involves requesting different 128k chunks of a 200GB file using the HTTP Range header. The URLs will all be the same, but the headers should vary from request to request to produce a realistic workload.
Is it possible to do this with siege?
[error] socket: connection timed out with only 3 concurrent users
I read that this error could appear when you do overkill on concurrent users. But with 3 users this seems very odd to me.
Any idea's?
This is my output:
root@booter:~# siege -c3 10.133.4.192:333
[alert] Zip encoding disabled; siege requires zlib support to enable it
** SIEGE 4.0.1
** Preparing 3 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200 0.57 secs: 71057 bytes ==> GET /
HTTP/1.1 200 0.58 secs: 71057 bytes ==> GET /
HTTP/1.1 200 0.58 secs: 71057 bytes ==> GET /
HTTP/1.1 200 0.00 secs: 1518 bytes ==> GET /wp-includes/js/wp-embed.min.js?ver=4.4.2
HTTP/1.1 200 0.00 secs: 1518 bytes ==> GET /wp-includes/js/wp-embed.min.js?ver=4.4.2
HTTP/1.1 200 0.00 secs: 13877 bytes ==> GET /wp-content/themes/inovado/framework/js/twitter/jquery.tweet.js?ver=1.0
HTTP/1.1 200 0.00 secs: 13877 bytes ==> GET /wp-content/themes/inovado/framework/js/twitter/jquery.tweet.js?ver=1.0
HTTP/1.1 200 0.00 secs: 21506 bytes ==> GET /wp-content/themes/inovado/framework/js/prettyPhoto.js?ver=3.1
HTTP/1.1 200 0.00 secs: 21506 bytes ==> GET /wp-content/themes/inovado/framework/js/prettyPhoto.js?ver=3.1
HTTP/1.1 200 0.00 secs: 1518 bytes ==> GET /wp-includes/js/wp-embed.min.js?ver=4.4.2
HTTP/1.1 200 0.00 secs: 3953 bytes ==> GET /wp-content/themes/inovado/framework/js/functions.js?ver=1.0
HTTP/1.1 200 0.00 secs: 13877 bytes ==> GET /wp-content/themes/inovado/framework/js/twitter/jquery.tweet.js?ver=1.0
HTTP/1.1 200 0.00 secs: 1610 bytes ==> GET /wp-content/themes/inovado/framework/js/waypoints-sticky.js?ver=1.4
HTTP/1.1 200 0.00 secs: 21506 bytes ==> GET /wp-content/themes/inovado/framework/js/prettyPhoto.js?ver=3.1
HTTP/1.1 200 0.01 secs: 8044 bytes ==> GET /wp-content/themes/inovado/framework/js/waypoints.js?ver=2.0.2
HTTP/1.1 200 0.01 secs: 3953 bytes ==> GET /wp-content/themes/inovado/framework/js/functions.js?ver=1.0
HTTP/1.1 200 0.01 secs: 3953 bytes ==> GET /wp-content/themes/inovado/framework/js/functions.js?ver=1.0
HTTP/1.1 200 0.00 secs: 1920 bytes ==> GET /wp-content/themes/inovado/framework/js/mobilemenu.js?ver=1.0
HTTP/1.1 200 0.00 secs: 1610 bytes ==> GET /wp-content/themes/inovado/framework/js/waypoints-sticky.js?ver=1.4
HTTP/1.1 200 0.00 secs: 1610 bytes ==> GET /wp-content/themes/inovado/framework/js/waypoints-sticky.js?ver=1.4
HTTP/1.1 200 0.00 secs: 8995 bytes ==> GET /wp-content/themes/inovado/framework/js/superfish.js?ver=1.4
HTTP/1.1 200 0.00 secs: 8044 bytes ==> GET /wp-content/themes/inovado/framework/js/waypoints.js?ver=2.0.2
HTTP/1.1 200 0.00 secs: 8044 bytes ==> GET /wp-content/themes/inovado/framework/js/waypoints.js?ver=2.0.2
HTTP/1.1 200 0.00 secs: 1920 bytes ==> GET /wp-content/themes/inovado/framework/js/mobilemenu.js?ver=1.0
HTTP/1.1 200 0.00 secs: 8371 bytes ==> GET /wp-content/themes/inovado/framework/js/bootstrap.js?ver=1.0
HTTP/1.1 200 0.00 secs: 1920 bytes ==> GET /wp-content/themes/inovado/framework/js/mobilemenu.js?ver=1.0
HTTP/1.1 200 0.00 secs: 4845 bytes ==> GET /wp-content/themes/inovado/framework/js/shortcodes.js?ver=1.0
HTTP/1.1 200 0.00 secs: 8995 bytes ==> GET /wp-content/themes/inovado/framework/js/superfish.js?ver=1.4
HTTP/1.1 200 0.00 secs: 8995 bytes ==> GET /wp-content/themes/inovado/framework/js/superfish.js?ver=1.4
HTTP/1.1 200 0.01 secs: 16688 bytes ==> GET /wp-content/plugins/flexslider/assets/js/jquery.flexslider.min.js?ver=2.1.0-20121206
HTTP/1.1 200 0.01 secs: 8371 bytes ==> GET /wp-content/themes/inovado/framework/js/bootstrap.js?ver=1.0
HTTP/1.1 200 0.01 secs: 8371 bytes ==> GET /wp-content/themes/inovado/framework/js/bootstrap.js?ver=1.0
HTTP/1.1 200 0.00 secs: 1007 bytes ==> GET /wp-content/plugins/flexslider/assets/js/jquery.mousewheel.min.js?ver=2.1.0-20121206
HTTP/1.1 200 0.00 secs: 4845 bytes ==> GET /wp-content/themes/inovado/framework/js/shortcodes.js?ver=1.0
HTTP/1.1 200 0.00 secs: 4845 bytes ==> GET /wp-content/themes/inovado/framework/js/shortcodes.js?ver=1.0
HTTP/1.1 200 0.00 secs: 11819 bytes ==> GET /wp-content/plugins/contact-form-7/includes/js/scripts.js?ver=4.4
HTTP/1.1 200 0.00 secs: 16688 bytes ==> GET /wp-content/plugins/flexslider/assets/js/jquery.flexslider.min.js?ver=2.1.0-20121206
HTTP/1.1 200 0.00 secs: 16688 bytes ==> GET /wp-content/plugins/flexslider/assets/js/jquery.flexslider.min.js?ver=2.1.0-20121206
HTTP/1.1 200 0.00 secs: 15248 bytes ==> GET /wp-content/plugins/contact-form-7/includes/js/jquery.form.min.js?ver=3.51.0-2014.06.20
HTTP/1.1 200 0.00 secs: 1007 bytes ==> GET /wp-content/plugins/flexslider/assets/js/jquery.mousewheel.min.js?ver=2.1.0-20121206
HTTP/1.1 200 0.00 secs: 1007 bytes ==> GET /wp-content/plugins/flexslider/assets/js/jquery.mousewheel.min.js?ver=2.1.0-20121206
HTTP/1.1 200 0.00 secs: 1078 bytes ==> GET /wp-includes/js/comment-reply.min.js?ver=4.4.2
HTTP/1.1 200 0.00 secs: 11819 bytes ==> GET /wp-content/plugins/contact-form-7/includes/js/scripts.js?ver=4.4
HTTP/1.1 200 0.00 secs: 11819 bytes ==> GET /wp-content/plugins/contact-form-7/includes/js/scripts.js?ver=4.4
HTTP/1.1 200 0.00 secs: 15248 bytes ==> GET /wp-content/plugins/contact-form-7/includes/js/jquery.form.min.js?ver=3.51.0-2014.06.20
HTTP/1.1 200 0.00 secs: 15248 bytes ==> GET /wp-content/plugins/contact-form-7/includes/js/jquery.form.min.js?ver=3.51.0-2014.06.20
HTTP/1.1 200 0.00 secs: 1078 bytes ==> GET /wp-includes/js/comment-reply.min.js?ver=4.4.2
HTTP/1.1 200 0.00 secs: 1078 bytes ==> GET /wp-includes/js/comment-reply.min.js?ver=4.4.2
[error] socket: -1303406848 connection timed out.: Connection timed out
[error] socket: -1311799552 connection timed out.: Connection timed out
[error] socket: -1295014144 connection timed out.: Connection timed out
make failure on centos
The same question with the url :#14 error info follow:
Making all in lib
make[1]: Entering directory /root/siege/lib' Making all in joedog make[2]: Entering directory/root/siege/lib/joedog'
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/openssl -I/usr/include -W -Wall -Wunused-value -g -O2 -c -o memory.lo memory.c
../../libtool: line 466: CDPATH: command not found
../../libtool: line 1144: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6b, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b
libtool: and run autoconf again.
make[2]: *** [memory.lo] Error 63
make[2]: Leaving directory /root/siege/lib/joedog' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/root/siege/lib'
make: *** [all-recursive] Error 1
strange behavior of siege (400 error code)
[dmitry:~/Development]$ siege -c 1 -r 5 -g http://site.com
HEAD / HTTP/1.0
Host: site.com
Accept: */*
User-Agent: Mozilla/5.0 (unknown-x86_64-linux-gnu) Siege/4.0.2
Connection: close
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 51115
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.5
Set-Cookie: Nop.customer=c6f12fca-121a-4723-a381-5eb61201065f; expires=Wed, 16-Aug-2017 00:26:15 GMT; path=/; HttpOnly
Date: Tue, 16 Aug 2016 00:26:15 GMT
Connection: close
Transactions: 1 hits
Availability: 100.00 %
Elapsed time: 0.32 secs
Data transferred: 0.00 MB
Response time: 0.29 secs
Transaction rate: 3.12 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 0.91
Successful transactions: 1
Failed transactions: 0
Longest transaction: 0.29
Shortest transaction: 0.29
as you can see single transaction succeeded with HTTP 200 OK response, however if -g option is removed, I get this:
[dmitry:~/Development]$ siege -c 1 -r 5 http://domain.com
** SIEGE 4.0.2
** Preparing 1 concurrent users for battle.
The server is now under siege...
HTTP/1.1 400 0.03 secs: 311 bytes ==> GET /
HTTP/1.1 400 0.02 secs: 311 bytes ==> GET /
HTTP/1.1 400 0.03 secs: 311 bytes ==> GET /
HTTP/1.1 400 0.03 secs: 311 bytes ==> GET /
HTTP/1.1 400 0.02 secs: 311 bytes ==> GET /
Transactions: 5 hits
Availability: 100.00 %
Elapsed time: 1.23 secs
Data transferred: 0.00 MB
Response time: 0.03 secs
Transaction rate: 4.07 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 0.11
Successful transactions: 0
Failed transactions: 0
Longest transaction: 0.03
Shortest transaction: 0.00
so all transaction failed with 400 status. At the same time server doesn't do any throttling and Apache's ab worked just fine:
[dmitry:~/Development]$ ab -c 1 -n 5 http://site.com/
This is ApacheBench, Version 2.3 <$Revision: 1748469 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking site.com (be patient).....done
Server Software: Microsoft-IIS/8.5
Server Hostname: site.com
Server Port: 80
Document Path: /
Document Length: 51115 bytes
Concurrency Level: 1
Time taken for tests: 1.847 seconds
Complete requests: 5
Failed requests: 0
Total transferred: 258060 bytes
HTML transferred: 255575 bytes
Requests per second: 2.71 [#/sec] (mean)
Time per request: 369.339 [ms] (mean)
Time per request: 369.339 [ms] (mean, across all concurrent requests)
Transfer rate: 136.47 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 13 13 0.7 14 14
Processing: 326 356 60.2 330 463
Waiting: 284 314 59.2 290 420
Total: 339 369 60.5 344 477
WARNING: The median and mean for the initial connection time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 344
66% 344
75% 344
80% 477
90% 477
95% 477
98% 477
99% 477
100% 477 (longest request)
any idea what's wrong?
thanks,
Dmitry
IPv6 support
If host has only AAAA record (ipv6 address) then siege fails with errors
[error] descriptor table full sock.c:108: Too many open files
[error] descriptor table full sock.c:108: Too many open files
Command siege -b https://2a02:6b8:0:1a79::f90 -v also raises these errors.
Ignore ssl certificate problems
Can you add this feature?
Thanks
Build issue
siege-4.0.1 can not be build on Fedora 23
make[1]: Entering directory '/home/fab/Documents/repos/packages/siege/siege-4.0.1/siege-4.0.1/src'
gcc -DHAVE_CONFIG_H -I. -I../include -I/include/zlib -I/include -I/usr/include/openssl -I/usr/include -I/include/zlib -I/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -DOPENSSL_NO_KRB5 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -c -o array.o array.c
In file included from array.c:27:0:
./array.h:37:36: error: unknown type name āmethodā
ARRAY array_destroyer(ARRAY this, method m);
^
./array.h:38:40: error: unknown type name āmethodā
void array_set_destroyer(ARRAY this, method m);
^
array.c:37:3: error: unknown type name āmethodā
method free;
^
array.c: In function ānew_arrayā:
array.c:50:16: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
this->free = NULL;
^
array.c: In function āarray_destroyā:
array.c:61:18: warning: comparison between pointer and integer
if (this->free == NULL) {
^
array.c:62:16: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
this->free = free;
^
array.c:66:5: error: called object is not a function or function pointer
this->free(this->data[i]);
^
array.c: At top level:
array.c:75:29: error: unknown type name āmethodā
array_destroyer(ARRAY this, method m)
^
array.c:82:33: error: unknown type name āmethodā
array_set_destroyer(ARRAY this, method m)
^
Makefile:453: recipe for target 'array.o' failed
$ rpm -q gcc
gcc-5.3.1-6.fc23.x86_64
Preflight load testing
Hi Joe,
I've been looking for some indication that siege handles preflight OPTIONS requests for POST. The answer seems to be no, but I would like to be sure.
Thanks for the excellent code.
Wilfred
Feature request: Static cookies
Currently if response sends Set-cookie: header siege will set the cookie and next time use updated version of cookie instead of the one given via --header.
Need for such feature comes from CodeIgniter framework which doesn't use PHPSESSION cookie and has it's own ci_session value which is updated on each request and it l for some reason logs user out(this may be application bug instead, not sure).
Something like --static-cookies or --ignore-set-cookies switch would be nice :) And shouldn't be hard to implement.
Print header
When siege testing it would be useful to be able to identify a slow server. If it were possible to specify an extra HTTP header that would be printed for each line (eg. X-Frontsever) along with the status code and url it would be helpful!
BSD Incompatible option used in bombardment
Line 43 in 05c4b3d
The option --iso-8601=minutes is not supported in BSD date, and results in the following error:
date: illegal option -- -
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
siege hangs sometimes
[root@node9 proc]# siege --version
SIEGE 2.72
Copyright (C) 2012 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.
siege work on:
[root@node9 proc]# cat /etc/centos-release
CentOS release 6.6 (Final)
siege run with command:
sh -c "/usr/bin/siege -c 4 -f /tmp/load_testser_0.955169454146.urls -d 10 -r1 -i;" 2>&1
sometimes siege process goto sleep mode:
[root@node9 proc]# cat 13721/status
Name: siege
State: S (sleeping)
Tgid: 13721
Pid: 13721
PPid: 13720
TracerPid: 0
Uid: 500 500 500 500
Gid: 100 100 100 100
Utrace: 0
FDSize: 64
Groups: 100
envID: 988
VPid: 13721
StopState: 0
VmPeak: 416100 kB
VmSize: 354740 kB
VmLck: 0 kB
VmHWM: 2984 kB
VmRSS: 2828 kB
VmData: 313628 kB
VmStk: 88 kB
VmExe: 100 kB
VmLib: 5760 kB
VmPTE: 140 kB
VmPTD: 28 kB
VmSwap: 0 kB
Threads: 3
SigQ: 0/253781
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000006003
SigIgn: 0000000001001002
SigCgt: 0000000180000000
SigSvd: 0000000000000000
CapInh: 00000000fdccffff
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000fdccffff
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 6
nonvoluntary_ctxt_switches: 4
TaskUB: 988
MMUB: 988
try to view some info via pstack:
[root@node9 proc]# pstack 13721
Thread 3 (Thread 0x7f126b930700 (LWP 13725)):
#0 0x00007f126ebcc453 in select () from /lib64/libc.so.6
#1 0x000000000040ea93 in ?? ()
#2 0x000000000040ec38 in ?? ()
#3 0x000000000040897f in ?? ()
#4 0x0000000000404c43 in ?? ()
#5 0x0000000000405642 in ?? ()
#6 0x0000000000406e45 in ?? ()
#7 0x00007f126f8ef9d1 in start_thread () from /lib64/libpthread.so.0
#8 0x00007f126ebd39dd in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f126af2f700 (LWP 13726)):
#0 0x00007f126f8f74b5 in sigwait () from /lib64/libpthread.so.0
#1 0x0000000000407e52 in ?? ()
#2 0x00007f126f8ef9d1 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f126ebd39dd in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f126fd157c0 (LWP 13721)):
#0 0x00007f126f8f022d in pthread_join () from /lib64/libpthread.so.0
#1 0x000000000040688b in ?? ()
#2 0x000000000040c8ed in ?? ()
#3 0x00007f126eb09d5d in __libc_start_main () from /lib64/libc.so.6
#4 0x0000000000403119 in ?? ()
#5 0x00007fffe384fd88 in ?? ()
#6 0x000000000000001c in ?? ()
#7 0x0000000000000009 in ?? ()
#8 0x00007fffe3850cf7 in ?? ()
#9 0x00007fffe3850d06 in ?? ()
#10 0x00007fffe3850d09 in ?? ()
#11 0x00007fffe3850d0b in ?? ()
#12 0x00007fffe3850d0e in ?? ()
#13 0x00007fffe3850d34 in ?? ()
#14 0x00007fffe3850d37 in ?? ()
#15 0x00007fffe3850d3a in ?? ()
#16 0x00007fffe3850d3e in ?? ()
#17 0x0000000000000000 in ?? ()
siege wait for "futex_wait_queue_me" to complete
[root@node9 proc]# cat /proc/13721/wchan
futex_wait_queue_me
root@node9 proc]# cat /proc/13721/stack
[<ffffffff810b4059>] futex_wait_queue_me+0xb9/0xf0
[<ffffffff810b5168>] futex_wait+0x1f8/0x380
[<ffffffff810b6911>] do_futex+0x161/0xbe0
[<ffffffff810b740b>] sys_futex+0x7b/0x170
[<ffffffff8100b102>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
CSV and Charting Support ?
@JoeDog love it that you're on Github easier to make suggestions and feature requests :)
Any plans for adding csv output and/or charting support for Siege ?
Segmentation fault
Hi,
SIEGE 4.0.2 on FreeBSD 10.2-STABLE
Running "siege -c 10 -i -f urls8.txt" will after a random time interval segfault.
back trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 801c08c00 (LWP 101440/siege)]
0x0000000801421fd0 in strncasecmp_l () from /lib/libc.so.7
(gdb) bt
#0 0x0000000801421fd0 in strncasecmp_l () from /lib/libc.so.7
#1 0x0000000000414fdf in ?? ()
#2 0x0000000000407813 in ?? ()
#3 0x0000000000406fd9 in ?? ()
#4 0x000000000040b7cb in ?? ()
#5 0x000000080084b855 in pthread_create () from /lib/libthr.so.3
#6 0x0000000000000000 in ?? ()
Any ideas?
Thanks,
Default log location doesn't honour prefix
I just installed Siege 3.1.4 on an Ubuntu 16.04 server with the prefix configured as my homedir, so by using:
./configure --prefix=/home/jan
It all went well and I got siege up and running. But at the end of a siege, it says:
LOG FILE: /usr/local/var/siege.log
You can disable this log file notification by editing
/home/jan/.siege/siege.conf and changing 'show-logfile' to false.
[error] unable to create log file: /usr/local/var/siege.log: No such file or directory
Since I'm running siege as my local user and Ubuntu doesn't have a var dir under /usr/local by default, it cannot write the log file.
But, the help text says:
-l, --log[=FILE] LOG to FILE. If FILE is not specified, the
default is used: PREFIX/var/siege.log
Obviously it's not using the PREFIX dir at all. It's going straight for /usr/local.
If I manually define the log file to be saved in my homedir it works just fine, but the help text doesn't match the default behaviour.
The cleanest solution would be to actually honour the PREFIX that was set during installation.
why the number of transactions is greater than the number of successful transactions
while using siege for load test, I got the result as following:
Transactions: 0 hits
Availability: 0.00 %
Elapsed time: 3.48 secs
Data transferred: 0.00 MB
Response time: 0.00 secs
Transaction rate: 0.00 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 2.97
Successful transactions: 182
Failed transactions: 0
Longest transaction: 0.14
Shortest transaction: 0.04
I use command line: siege -c3 -r1 -f url_test.txt , in url_test.txt file there is only one
url:http://www.amazon.cn/s?ie=UTF8&page=1&rh=n%3A664978051,k%3A%E6%9C%B5%E5%94%AF%E6%89%8B%E6%9C%BA,p_n_feature_seven_browse-bin%3A2147037051
when siege running, the verbose output always like "HTTP/1.1 301 *****" and the http request are executed so many time that it only can be stopped by enter "Ctrl + C". I want to know what happened ,and how to solve this ? thanks~~
siege/head `make` fail @ libtool mismatch
on linux/64
lsb_release -rd
Description: openSUSE Leap 42.1 (x86_64)
Release: 42.1
gcc --version
gcc (SUSE Linux) 5.3.1 20160212 [gcc-5-branch revision 233369]
autoconf --version
autoconf (GNU Autoconf) 2.69
libtoolize --version
libtoolize (GNU libtool) 2.4.6
building siege/HEAD
git clone https://github.com/JoeDog/siege.git
cd siege
git log | head
commit 6f9cdef7fa5b0d77d36273571c8b20cb3bf00583
Author: J. Fulmer <[email protected]>
Date: Thu Feb 18 20:31:45 2016 -0500
Routine update: 4.0.0-beta7
commit 883c926f2b2c357b7d17913478a8c7f2f8f52596
Author: J. Fulmer <[email protected]>
Date: Thu Feb 18 20:24:29 2016 -0500
autoreconf -vif
./configure \
--prefix=/usr/local/siege \
--with-ssl=/usr/local/ssl \
--with-gnu-ld
fails @ make
make V=1
...
Making all in joedog
make[2]: Entering directory '/usr/local/src/siege/lib/joedog'
/bin/sh ../../libtool --tag=CC --mode=compile /usr/bin/gcc-5 -DHAVE_CONFIG_H -I. -I../../include -I/include/zlib -I/include -W -Wall -Wunused-value -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=x86-64 -mtune=nocona -c -o memory.lo memory.c
libtool: Version mismatch error. This is libtool 2.4.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6
libtool: and run autoconf again.
Makefile:378: recipe for target 'memory.lo' failed
make[2]: *** [memory.lo] Error 63
make[2]: Leaving directory '/usr/local/src/siege/lib/joedog'
Makefile:364: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/local/src/siege/lib'
Makefile:398: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
re-exec libtool macros+autoconf
make clean
libtoolize
autoconf -v -f
doesn't cure
./configure \
--prefix=/usr/local/siege \
--with-ssl=/usr/local/ssl \
--with-gnu-ld
make V=1
...
Making all in joedog
make[2]: Entering directory '/usr/local/src/siege/lib/joedog'
/bin/sh ../../libtool --tag=CC --mode=compile /usr/bin/gcc-5 -DHAVE_CONFIG_H -I. -I../../include -I/include/zlib -I/include -W -Wall -Wunused-value -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches -march=x86-64 -mtune=nocona -c -o memory.lo memory.c
libtool: Version mismatch error. This is libtool 2.4.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6
libtool: and run autoconf again.
Makefile:378: recipe for target 'memory.lo' failed
make[2]: *** [memory.lo] Error 63
make[2]: Leaving directory '/usr/local/src/siege/lib/joedog'
Makefile:364: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/local/src/siege/lib'
Makefile:398: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
Segfaults on just over -c580
-c600 segfaults for sure. tested on centos7 and debian jessie
following from jessie siege version 3.0.8
*** buffer overflow detected ***: siege terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x731ff)[0x7f3c25cd91ff]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f3c25d5c4c7]
/lib/x86_64-linux-gnu/libc.so.6(+0xf46e0)[0x7f3c25d5a6e0]
/lib/x86_64-linux-gnu/libc.so.6(+0xf6437)[0x7f3c25d5c437]
siege(+0x13f38)[0x7f3c26cc1f38]
siege(+0x8648)[0x7f3c26cb6648]
siege(+0x884d)[0x7f3c26cb684d]
siege(+0x9891)[0x7f3c26cb7891]
siege(+0xad31)[0x7f3c26cb8d31]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7f3c268760a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f3c25d4c04d]
======= Memory map: ========
*** buffer overflow detected ***: siege terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x731ff)[0x7f3c25cd91ff]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f3c25d5c4c7]
/lib/x86_64-linux-gnu/libc.so.6(+0xf46e0)[0x7f3c25d5a6e0]
/lib/x86_64-linux-gnu/libc.so.6(+0xf6437)[0x7f3c25d5c437]
siege(+0x13f38)[0x7f3c26cc1f38]
siege(+0x8648)[0x7f3c26cb6648]
siege(+0x884d)[0x7f3c26cb684d]
siege(+0x9891)[0x7f3c26cb7891]
siege(+0xad31)[0x7f3c26cb8d31]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7f3c268760a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f3c25d4c04d]
======= Memory map: ========
7f3ad4000000-7f3ad408d000 rw-p 00000000 00:00 0
7f3ad408d000-7f3ad8000000 ---p 00000000 00:00 0
7f3adc000000-7f3adc091000 rw-p 00000000 00:00 0
7f3adc091000-7f3ae0000000 ---p 00000000 00:00 0
7f3ae0000000-7f3ae008d000 rw-p 00000000 00:00 0
7f3ae008d000-7f3ae4000000 ---p 00000000 00:00 0
7f3ae4000000-7f3ae4085000 rw-p 00000000 00:00 0
7f3ae4085000-7f3ae8000000 ---p 00000000 00:00 0
7f3ae8000000-7f3ae809a000 rw-p 00000000 00:00 0
7f3ae809a000-7f3aec000000 ---p 00000000 00:00 0
7f3aec000000-7f3aec096000 rw-p 00000000 00:00 0
7f3aec096000-7f3af0000000 ---p 00000000 00:00 0
7f3af0000000-7f3af008d000 rw-p 00000000 00:00 0
7f3af008d000-7f3af4000000 ---p 00000000 00:00 0
7f3af4000000-7f3af4086000 rw-p 00000000 00:00 0
7f3af4086000-7f3af8000000 ---p 00000000 00:00 0
7f3af89ce000-7f3af89e4000 r-xp 00000000 fe:01 652804 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f3af89e4000-7f3af8be3000 ---p 00016000 fe:01 652804 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f3af8be3000-7f3af8be4000 rw-p 00015000 fe:01 652804 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f3af8be4000-7f3af8bf8000 r-xp 00000000 fe:01 652811 /lib/x86_64-linux-gnu/libresolv-2.19.so
7f3af8bf8000-7f3af8df7000 ---p 00014000 fe:01 652811 /lib/x86_64-linux-gnu/libresolv-2.19.so
7f3af8df7000-7f3af8df8000 r--p 00013000 fe:01 652811 /lib/x86_64-linux-gnu/libresolv-2.19.so
7f3af8df8000-7f3af8df9000 rw-p 00014000 fe:01 652811 /lib/x86_64-linux-gnu/libresolv-2.19.so
7f3af8df9000-7f3af8dfb000 rw-p 00000000 00:00 0
7f3af8dfb000-7f3af8e00000 r-xp 00000000 fe:01 652814 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7f3af8e00000-7f3af8fff000 ---p 00005000 fe:01 652814 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7f3af8fff000-7f3af9000000 r--p 00004000 fe:01 652814 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7f3af9000000-7f3af9001000 rw-p 00005000 fe:01 652814 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7f3af9001000-7f3af900c000 r-xp 00000000 fe:01 652809 /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f3af900c000-7f3af920b000 ---p 0000b000 fe:01 652809 /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f3af920b000-7f3af920c000 r--p 0000a000 fe:01 652809 /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f3af920c000-7f3af920d000 rw-p 0000b000 fe:01 652809 /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f3af920d000-7f3af920e000 ---p 00000000 00:00 0
7f3af920e000-7f3af9a0e000 rw-p 00000000 00:00 0 [stack:10074]
7f3af9a0e000-7f3af9a0f000 ---p 00000000 00:00 0
7f3af9a0f000-7f3afa20f000 rw-p 00000000 00:00 0 [stack:10073]
7f3afa20f000-7f3afa210000 ---p 00000000 00:00 0
7f3afa210000-7f3afaa10000 rw-p 00000000 00:00 0 [stack:10072]
7f3afaa10000-7f3afaa11000 ---p 00000000 00:00 0
7f3afaa11000-7f3afb211000 rw-p 00000000 00:00 0 [stack:10071]
7f3afb211000-7f3afb212000 ---p 00000000 00:00 0
7f3afb212000-7f3afba12000 rw-p 00000000 00:00 0 [stack:10070]
7f3afba12000-7f3afba13000 ---p 00000000 00:00 0
7f3afba13000-7f3afc213000 rw-p 00000000 00:00 0 [stack:10069]
7f3afc213000-7f3afc214000 ---p 00000000 00:00 0
7f3afc214000-7f3afca14000 rw-p 00000000 00:00 0 [stack:10068]
7f3afca14000-7f3afca15000 ---p 00000000 00:00 0
7f3afca15000-7f3afd215000 rw-p 00000000 00:00 0 [stack:10067]
7f3afd215000-7f3afd216000 ---p 00000000 00:00 0
7f3afd216000-7f3afda16000 rw-p 00000000 00:00 0 [stack:10066]
7f3afda16000-7f3afda17000 ---p 00000000 00:00 0
7f3afda17000-7f3afe217000 rw-p 00000000 00:00 0 [stack:10065]
7f3afe217000-7f3afe218000 ---p 00000000 00:00 0
7f3afe218000-7f3afea18000 rw-p 00000000 00:00 0 [stack:10064]
7f3afea18000-7f3afea19000 ---p 00000000 00:00 0
7f3afea19000-7f3aff219000 rw-p 00000000 00:00 0 [stack:10063]
7f3aff219000-7f3aff21a000 ---p 00000000 00:00 0
7f3aff21a000-7f3affa1a000 rw-p 00000000 00:00 0 [stack:10062]
7f3affa1a000-7f3affa1b000 ---p 00000000 00:00 0
7f3affa1b000-7f3b0021b000 rw-p 00000000 00:00 0 [stack:10061]
7f3b0021b000-7f3b0021c000 ---p 00000000 00:00 0
7f3b0021c000-7f3b00a1c000 rw-p 00000000 00:00 0 [stack:10060]
7f3b00a1c000-7f3b00a1d000 ---p 00000000 00:00 0
7f3b00a1d000-7f3b0121d000 rw-p 00000000 00:00 0 [stack:10059]
7f3b0121d000-7f3b0121e000 ---p 00000000 00:00 0
7f3b0121e000-7f3b01a1e000 rw-p 00000000 00:00 0 [stack:10058]
7f3b01a1e000-7f3b01a1f000 ---p 00000000 00:00 0
7f3b01a1f000-7f3b0221f000 rw-p 00000000 00:00 0 [stack:10057]
7f3b0221f000-7f3b02220000 ---p 00000000 00:00 0
7f3b02220000-7f3b02a20000 rw-p 00000000 00:00 0 [stack:10056]
7f3b02a20000-7f3b02a21000 ---p 00000000 00:00 0
7f3b02a21000-7f3b03221000 rw-p 00000000 00:00 0 [stack:10055]
7f3b03221000-7f3b03222000 ---p 00000000 00:00 0
7f3b03222000-7f3b03a22000 rw-p 00000000 00:00 0 [stack:10054]
7f3b03a22000-7f3b03a23000 ---p 00000000 00:00 0
7f3b03a23000-7f3b04223000 rw-p 00000000 00:00 0 [stack:10053]
7f3b04223000-7f3b04224000 ---p 00000000 00:00 0
7f3b04224000-7f3b04a24000 rw-p 00000000 00:00 0 [stack:10052]
7f3b04a24000-7f3b04a25000 ---p 00000000 00:00 0
7f3b04a25000-7f3b05225000 rw-p 00000000 00:00 0 [stack:10051]
7f3b05225000-7f3b05226000 ---p 00000000 00:00 0
7f3b05226000-7f3b05a26000 rw-p 00000000 00:00 0 [stack:10050]
7f3b05a26000-7f3b05a27000 ---p 00000000 00:00 0
7f3b05a27000-7f3b06227000 rw-p 00000000 00:00 0 [stack:10049]
7f3b06227000-7f3b06228000 ---p 00000000 00:00 0
7f3b06228000-7f3b06a28000 rw-p 00000000 00:00 0 [stack:10048]
7f3b06a28000-7f3b06a29000 ---p 00000000 00:00 0
7f3b06a29000-7f3b07229000 rw-p 00000000 00:00 0 [stack:10047]
7f3b07229000-7f3b0722a000 ---p 00000000 00:00 0
7f3b0722a000-7f3b07a2a000 rw-p 00000000 00:00 0 [stack:10046]
7f3b07a2a000-7f3b07a2b000 ---p 00000000 00:00 0
7f3b07a2b000-7f3b0822b000 rw-p 00000000 00:00 0 [stack:10045]
7f3b0822b000-7f3b0822c000 ---p 00000000 00:00 0
7f3b0822c000-7f3b08a2c000 rw-p 00000000 00:00 0 [stack:10044]
7f3b08a2c000-7f3b08a2d000 ---p 00000000 00:00 0
7f3b08a2d000-7f3b0922d000 rw-p 00000000 00:00 0 [stack:10043]
7f3b0922d000-7f3b0922e000 ---p 00000000 00:00 0
7f3b0922e000-7f3b09a2e000 rw-p 00000000 00:00 0 [stack:10042]
7f3b09a2e000-7f3b09a2f000 ---p 00000000 00:00 0
7f3b09a2f000-7f3b0a22f000 rw-p 00000000 00:00 0 [stack:10041]
7f3b0a22f0007f3ad4000000-7f3ad408d000 rw-p 00000000 00:00 0
7f3ad408d000-7f3ad8000000 ---p 00000000 00:00 0
7f3adc000000-7f3adc091000 rw-p 00000000 00:00 0
7f3adc091000-7f3ae0000000 ---p 00000000 00:00 0
7f3ae0000000-7f3ae008d000 rw-p 00000000 00:00 0
7f3ae008d000-7f3ae4000000 ---p 00000000 00:00 0
7f3ae4000000-7f3ae4085000 rw-p 00000000 00:00 0
7f3ae4085000-7f3ae8000000 ---p 00000000 00:00 0
7f3ae8000000-7f3ae809a000 rw-p 00000000 00:00 0
7f3ae809a000-7f3aec000000 ---p 00000000 00:00 0
7f3aec000000-7f3aec096000 rw-p 00000000 00:00 0
7f3aec096000-7f3af0000000 ---p 00000000 00:00 0
7f3af0000000-7f3af008d000 rw-p 00000000 00:00 0
7f3af008d000-7f3af4000000 ---p 00000000 00:00 0
7f3af4000000-7f3af4086000 rw-p 00000000 00:00 0
7f3af4086000-7f3af8000000 ---p 00000000 00:00 0
7f3af89ce000-7f3af89e4000 r-xp 00000000 fe:01 652804 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f3af89e4000-7f3af8be3000 ---p 00016000 fe:01 652804 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f3af8be3000-7f3af8be4000 rw-p 00015000 fe:01 652804 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f3af8be4000-7f3af8bf8000 r-xp 00000000 fe:01 652811 /lib/x86_64-linux-gnu/libresolv-2.19.so
7f3af8bf8000-7f3af8df7000 ---p 00014000 fe:01 652811 /lib/x86_64-linux-gnu/libresolv-2.19.so
7f3af8df7000-7f3af8df8000 r--p 00013000 fe:01 652811 /lib/x86_64-linux-gnu/libresolv-2.19.so
7f3af8df8000-7f3af8df9000 rw-p 00014000 fe:01 652811 /lib/x86_64-linux-gnu/libresolv-2.19.so
7f3af8df9000-7f3af8dfb000 rw-p 00000000 00:00 0
7f3af8dfb000-7f3af8e00000 r-xp 00000000 fe:01 652814 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7f3af8e00000-7f3af8fff000 ---p 00005000 fe:01 652814 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7f3af8fff000-7f3af9000000 r--p 00004000 fe:01 652814 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7f3af9000000-7f3af9001000 rw-p 00005000 fe:01 652814 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
7f3af9001000-7f3af900c000 r-xp 00000000 fe:01 652809 /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f3af900c000-7f3af920b000 ---p 0000b000 fe:01 652809 /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f3af920b000-7f3af920c000 r--p 0000a000 fe:01 652809 /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f3af920c000-7f3af920d000 rw-p 0000b000 fe:01 652809 /lib/x86_64-linux-gnu/libnss_files-2.19.so
7f3af920d000-7f3af920e000 ---p 00000000 00:00 0
7f3af920e000-7f3af9a0e000 rw-p 00000000 00:00 0 [stack:10074]
7f3af9a0e000-7f3af9a0f000 ---p 00000000 00:00 0
7f3af9a0f000-7f3afa20f000 rw-p 00000000 00:00 0 [stack:10073]
7f3afa20f000-7f3afa210000 ---p 00000000 00:00 0
7f3afa210000-7f3afaa10000 rw-p 00000000 00:00 0 [stack:10072]
7f3afaa10000-7f3afaa11000 ---p 00000000 00:00 0
7f3afaa11000-7f3afb211000 rw-p 00000000 00:00 0 [stack:10071]
7f3afb211000-7f3afb212000 ---p 00000000 00:00 0
7f3afb212000-7f3afba12000 rw-p 00000000 00:00 0 [stack:10070]
7f3afba12000-7f3afba13000 ---p 00000000 00:00 0
7f3afba13000-7f3afc213000 rw-p 00000000 00:00 0 [stack:10069]
7f3afc213000-7f3afc214000 ---p 00000000 00:00 0
7f3afc214000-7f3afca14000 rw-p 00000000 00:00 0 [stack:10068]
7f3afca14000-7f3afca15000 ---p 00000000 00:00 0
7f3afca15000-7f3afd215000 rw-p 00000000 00:00 0 [stack:10067]
7f3afd215000-7f3afd216000 ---p 00000000 00:00 0
7f3afd216000-7f3afda16000 rw-p 00000000 00:00 0 [stack:10066]
7f3afda16000-7f3afda17000 ---p 00000000 00:00 0
7f3afda17000-7f3afe217000 rw-p 00000000 00:00 0 [stack:10065]
7f3afe217000-7f3afe218000 ---p 00000000 00:00 0
7f3afe218000-7f3afea18000 rw-p 00000000 00:00 0 [stack:10064]
7f3afea18000-7f3afea19000 ---p 00000000 00:00 0
7f3afea19000-7f3aff219000 rw-p 00000000 00:00 0 [stack:10063]
7f3aff219000-7f3aff21a000 ---p 00000000 00:00 0
7f3aff21a000-7f3affa1a000 rw-p 00000000 00:00 0 [stack:10062]
7f3affa1a000-7f3affa1b000 ---p 00000000 00:00 0
7f3affa1b000-7f3b0021b000 rw-p 00000000 00:00 0 [stack:10061]
7f3b0021b000-7f3b0021c000 ---p 00000000 00:00 0
7f3b0021c000-7f3b00a1c000 rw-p 00000000 00:00 0 [stack:10060]
7f3b00a1c000-7f3b00a1d000 ---p 00000000 00:00 0
7f3b00a1d000-7f3b0121d000 rw-p 00000000 00:00 0 [stack:10059]
7f3b0121d000-7f3b0121e000 ---p 00000000 00:00 0
7f3b0121e000-7f3b01a1e000 rw-p 00000000 00:00 0 [stack:10058]
7f3b01a1e000-7f3b01a1f000 ---p 00000000 00:00 0
7f3b01a1f000-7f3b0221f000 rw-p 00000000 00:00 0 [stack:10057]
7f3b0221f000-7f3b02220000 ---p 00000000 00:00 0
7f3b02220000-7f3b02a20000 rw-p 00000000 00:00 0 [stack:10056]
7f3b02a20000-7f3b02a21000 ---p 00000000 00:00 0
7f3b02a21000-7f3b03221000 rw-p 00000000 00:00 0 [stack:10055]
7f3b03221000-7f3b03222000 ---p 00000000 00:00 0
7f3b03222000-7f3b03a22000 rw-p 00000000 00:00 0 [stack:10054]
7f3b03a22000-7f3b03a23000 ---p 00000000 00:00 0
7f3b03a23000-7f3b04223000 rw-p 00000000 00:00 0 [stack:10053]
7f3b04223000-7f3b04224000 ---p 00000000 00:00 0
7f3b04224000-7f3b04a24000 rw-p 00000000 00:00 0 [stack:10052]
7f3b04a24000-7f3b04a25000 ---p 00000000 00:00 0
7f3b04a25000-7f3b05225000 rw-p 00000000 00:00 0 [stack:10051]
7f3b05225000-7f3b05226000 ---p 00000000 00:00 0
7f3b05226000-7f3b05a26000 rw-p 00000000 00:00 0 [stack:10050]
7f3b05a26000-7f3b05a27000 ---p 00000000 00:00 0
7f3b05a27000-7f3b06227000 rw-p 00000000 00:00 0 [stack:10049]
7f3b06227000-7f3b06228000 ---p 00000000 00:00 0
7f3b06228000-7f3b06a28000 rw-p 00000000 00:00 0 [stack:10048]
7f3b06a28000-7f3b06a29000 ---p 00000000 00:00 0
7f3b06a29000-7f3b07229000 rw-p 00000000 00:00 0 [stack:10047]
7f3b07229000-7f3b0722a000 ---p 00000000 00:00 0
7f3b0722a000-7f3b07a2a000 rw-p 00000000 00:00 0 [stack:10046]
7f3b07a2a000-7f3b07a2b000 ---p 00000000 00:00 0
7f3b07a2b000-7f3b0822b000 rw-p 00000000 00:00 0 [stack:10045]
7f3b0822b000-7f3b0822c000 ---p 00000000 00:00 0
7f3b0822c000-7f3b08a2c000 rw-p 00000000 00:00 0 [stack:10044]
7f3b08a2c000-7f3b08a2d000 ---p 00000000 00:00 0
7f3b08a2d000-7f3b0922d000 rw-p 00000000 00:00 0 [stack:10043]
7f3b0922d000-7f3b0922e000 ---p 00000000 00:00 0
7f3b0922e000-7f3b09a2e000 rw-p 00000000 00:00 0 [stack:10042]
7f3b09a2e000-7f3b09a2f000 ---p 00000000 00:00 0
7f3b09a2f000-7f3b0a22f000 rw-p 00000000 00:00 0 [stack:10041]
7f3b0a22f000-7f3b0a230000 ---p 00000000 00:00 0
7f3b0a230000-7f3b0aa30000 rw-p 00000000 00:00 0 [stack:10040]
7f3b0aa30000-7f3b0aa31000 ---p 00000000 00:00 0
7f3b0aa31000-7f3b0b231000 rw-p 00000000 00:00 0 [stack:10039]
7f3b0b231000-7f3b0b232000 ---p 00000000 00:00 0
7f3b0b232000-7f3b0ba32000 rw-p 00000000 00:00 0 [stack:10038]
7f3b0ba32000-7f3b0ba33000 ---p 00000000 00:00 0
7f3b0ba33000-7f3b0c233000 rw-p 00000000 00:00 0 [stack:10037]
7f3b0c233000-7f3b0c234000 ---p 00000000 00:00 0
7f3b0c234000-7f3b0ca34000 rw-p 00000000 00:00 0 [stack:10036]
7f3b0ca34000-7f3b0ca35000 ---p 00000000 00:00 0
7f3b0ca35000-7f3b0d235000 rw-p 00000000 00:00 0 [stack:10035]
7f3b0d235000-7f3b0d236000 ---p 00000000 00:00 0
7f3b0d236000-7f3b0da36000 rw-p 00000000 00:00 0 [stack:10034]
7f3b0da36000-7f3b0da37000 ---p 00000000 00:00 0
7f3b0da37000-7f3b0e237000 rw-p 0000Aborted
Siege's processing of chunked responses is so slow that benchmarks are totally off
Hi, I noticed that when running siege on a server of mine, it reported download and response times 5x to 10x slower than what the server can handle.
I also noticed that downloading with siege -c1 was 10x slower than downloading with curl or wget. I tested with a 4 MB file.
I spent many hours trying to debug my server, by chance I opened htop and noticed that Siege was running on 100% CPU on one core during the test, with the bar in htop being red (suggesting time is spent in kernel space).
After a quick read over the code, I noticed two issues:
- Siege uses
reallocin a way that leads to O(nĀ²) run time:realloc(ptr, size+MAXFILE);. This will result inrealloc(MAXFILE); realloc(MAXFILE*2); realloc(MAXFILE*3); ..., if you sum them all up, you get quadratic behaviour. Could you switch to exponential buffer growth (e.g.realloc(ptr, size*2)) to avoid this problem and make allocations O(n)? - Siege reads the response byte-by-byte
r = socket_read(C, &c, 1);when chunked encoding is used, which is extremely slow, since one syscall is made for each byte. That's the reason why the 100% CPU is spent in kernel space (a quick use ofperfconfirmed this). Ideally siege would read more than one byte persocket_readcall.
Especially the latter issue makes siege close to useless for benchmarking servers that do chunked encoding, because it's currently essentially measuring the calling machine's CPU speed.
From a quick test, something like the following patch seems to fix it, making siege just as fast as wget and curl at close to no CPU usage:
diff --git a/src/http.c b/src/http.c
index 3d98276..c5e9e62 100644
--- a/src/http.c
+++ b/src/http.c
@@ -620,22 +620,25 @@ http_read(CONN *C, RESPONSE resp)
continue;
}
while (n < chunk) {
- r = socket_read(C, &c, 1);
+ int remaining_in_chunk = chunk - n;
+ int space_in_buf = size - bytes;
+ int to_read = remaining_in_chunk < space_in_buf ? remaining_in_chunk : space_in_buf;
+ r = socket_read(C, &ptr[bytes], to_read); // TODO I didn't check this thoroughly
+ bytes += r;
if (r <= 0) {
done = TRUE;
break;
}
n += r;
if (bytes >= size) {
- tmp = realloc(ptr, size+MAXFILE);
+ tmp = realloc(ptr, size*2);
if (tmp == NULL) {
free(ptr);
return -1;
}
ptr = tmp;
- size += MAXFILE;
+ size *= 2;
}
- ptr[bytes++] = c;
}
n = 0;
} while (! done);But please don't apply this patch straight away, I did not spend much time checking whether the computation for to_read is precisely right, or off by 1 or 2 (especially because I haven't looked into where the \r\n at the end of the chunk is consumed).
URLs longer than 4KB kill siege with buffer overflow
I'm running down performance problems with a Solr server in an ecommerce setting. Some legitimate user requests cause the app to generate long queries listing lots of product ids. This produces URLs at least 10KB in length. Somewhere around the 4KB mark, siege dies saying:
*** buffer overflow detected ***: siege terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f526126238f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f52612f9c9c]
/lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f52612f8b60]
/lib/x86_64-linux-gnu/libc.so.6(+0x109069)[0x7f52612f8069]
/lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0xbc)[0x7f526126a70c]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x1cd5)[0x7f526123a9c5]
/lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x84)[0x7f52612f80f4]
/lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7f52612f804d]
siege(+0xe1a0)[0x7f52620401a0]
siege(+0x8abb)[0x7f526203aabb]
siege(+0x99d3)[0x7f526203b9d3]
siege(+0xae6e)[0x7f526203ce6e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f5261bf7182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f52612e947d]
This is on Ubuntu 14.04.4 LTS, kernel 3.13.0-85-generic.
It'd be nice if this just worked, but if not, it would be better to fail with a clear error message.
Not building for me on Ubuntu
Trying to build, however, when I run autoconf I get...
configure.ac:21: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:41: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.ac:47: error: possibly undefined macro: AC_PROG_SHELL
I have ensured AutoMake, AutoConf, and libtool are all installed. Any ideas?
Do not create $HOME/.siege if alternative siegerc is provided
If an alternative siegerc is provided via the -R, --rc=FILE parameter or the SIEGERC environment variable is set, the $HOME/.siege directory should not be created.
Cookie Expire updates being ignored
When we login to an application it sends the response with a cookie that times out after half an hour
Set-Cookie:session-key=xxxx;Path=/;Expires=Mon, 04-May-2015 09:58:27 GMT;Max-Age=604800
During subsequent requests the server updates the cookie to keep moving the expire half an hour forward.
Set-Cookie:session-key=xxxx;Path=/;Expires=Mon, 04-May-2015 10:00:52 GMT;Max-Age=604800
This means that the users session will expire after half an hour of inactivity.
Using siege to test the application I start getting 401 responses after half an hour, when due to requests being sent it should keep the users session active.
(I use the normal login setup in .siegerc)
This looks like siege is creating the cookie ok but ignoring future requests to update the timeout.
concurrency value coming up wrong
I am running latest version and concurrency computation seems to be wrong.
single threaded server
Lifting the server siege...
Transactions: 140 hits
Availability: 100.00 %
Elapsed time: 19.18 secs
Data transferred: 5.03 MB
Response time: 0.67 secs
Transaction rate: 7.30 trans/sec
Throughput: 0.26 MB/sec
Concurrency: 4.91
Successful transactions: 140
Failed transactions: 0
Longest transaction: 2.49
Shortest transaction: 0.24
versus multi-threaded server
Lifting the server siege...
Transactions: 641 hits
Availability: 100.00 %
Elapsed time: 19.80 secs
Data transferred: 23.03 MB
Response time: 0.15 secs
Transaction rate: 32.37 trans/sec
Throughput: 1.16 MB/sec
Concurrency: 4.97
Successful transactions: 641
Failed transactions: 0
Longest transaction: 2.44
Shortest transaction: 0.12
They both run for ~20 seconds, and multi-threaded one gets throughput benefit x5. Concurrency for the first one should have been close to 1, and other being close to 5 -- I have concurrent thread count as 5.
configure is missing from this git repository
It's in your tarball, but not in git.
Siege 4.0.1/4.0.2 hangs forever on 'Lifting the server siege...' with concurrency > 1
This happens repeatedly when I run with these arguments.
I have reproduced this one two platforms:
OSX, siege 4.0.1 installed from brew
Linux, siege 4.0.2 built from git, running on Debian Jesse in docker
siege -c 2 -t 5S -H "Host:www.mydomain.com" http://myelb.us-west-2.elb.amazonaws.com
If I strace the process it's hanging on a futex:
futex(0x7f3711c4d9d0, FUTEX_WAIT, 8511, NULL...
With the exact same arguments I can trigger the behavior when -c is any value over 1. -c 1 completes happily.
Add command-line option -p/--parser/--no-parser
Man page mentions non-existent option -p/--parser.
Would be nice to turn parser on/off from command-line instead of config file.
POST option does not take effect
Invoking siege (4.0.2) with the POST command, doesn't request with POST. I had a Java Spring Controller which is just available for post requests.
With following command:
siege -t 1M -H 'Content-Type: application/json' -H "Authorization: Bearer $token" "https://$host/api POST {}"
All siege requests result in 405s, since the server is rejecting them as GET requests:
HTTP/1.1 405 0.29 secs: 219 bytes ==> POST https://...
Segfault when no status line received
Siege expects a HTTP response with a valid status line (e.g. HTTP/1.0 200 OK).
It gets parsed here:
if (strncasecmp(line, "http", 4) == 0) {
response_set_code(resp, line);
}
and here:
BOOLEAN
response_set_code(RESPONSE this, char *line)
{ // we expect the start line: HTTP/1.0 200 OK
char *tmp = line;
char arr[32];
if (strncasecmp(line, "http", 4) == 0) {
int num = atoi(tmp+9);
if (num > 1) {
memset(arr, '\0', sizeof(arr));
strncpy(arr, line, 8);
hash_add(this->headers, PROTOCOL, arr);
hash_add(this->headers, RESPONSE_CODE, line+9);
return TRUE;
}
}
return FALSE;
}
If there is no such status line (or another line starting with "http" and having a number > 0 at position 9) in the header the entry RESPONSE_CODE in the headers dictionary will not be populated. On retrieval by hash_get a null pointer is be returned
In the functions response_get_code, response_success and response_failure the pointer from hash_get is thrown into atoi without further checking and it results in a segmentation fault, if RESPONSE_CODE is not found.
int
response_get_code(RESPONSE this)
{
return atoi((char *)hash_get(this->headers, RESPONSE_CODE));
}
Steps to reproduce:
echo -n "foo\r\n\r\n" | nc -lp 1337siege -c 1 -r 1 http://localhost:1337
Backtrace from GDB:
#0 0x00007f3d1dea0d45 in ____strtoll_l_internal () from /usr/lib/libc.so.6
#1 0x00007f3d1de9e2e0 in atoi () from /usr/lib/libc.so.6
#2 0x0000000000417b11 in response_success (this=0x7f3d1801c5b0)
at response.c:133
#3 0x0000000000405fbd in __http (this=0x1257890, U=0x1257580)
at browser.c:523
#4 0x0000000000405b25 in __request (this=0x1257890, U=0x1257580)
at browser.c:406
#5 0x000000000040561f in start (this=0x1257890) at browser.c:295
#6 0x000000000040b20f in crew_thread (crew=0x12579b0) at crew.c:141
#7 0x00007f3d1e425454 in start_thread () from /usr/lib/libpthread.so.0
#8 0x00007f3d1df527df in clone () from /usr/lib/libc.so.6
Support for CloudFlare SSL (TLS)
When trying to benchmark my https:// site with CloudFlare activated, I get this error:
[error] Failed to make an SSL connection
It works fine using the browser.
When disabling CloudFlare it works as expected (with a self signed SSL certificate), and also it works fine with other SSL sites.
I think it is related to CloudFlare's certificate requiring TLS for the connection, rather than SSLv3.
I guess Siege needs an option to specify the protocol to use?
how can I know what happened when there were failed transactions?
I got the result like this:
Transactions: 104875 hits
Availability: 99.03 %
Elapsed time: 18.73 secs
Data transferred: 18.93 MB
Response time: 0.01 secs
Transaction rate: 5599.31 trans/sec
Throughput: 1.01 MB/sec
Concurrency: 49.38
Successful transactions: 104875
Failed transactions: 1024
Longest transaction: 0.04
Shortest transaction: 0.00
There were 1024 failed transactions, but in the log file I only got 104875 normal response with status 200, and without any error message.
So, how can I know what happened?
Wrong statistics for failed transactions
When running siege localhost I see this output:
** SIEGE 4.0.1
** Preparing 25 concurrent users for battle.
The server is now under siege...
HTTP/1.1 403 0.00 secs: 168 bytes ==> GET /
HTTP/1.1 403 0.01 secs: 168 bytes ==> GET /
HTTP/1.1 403 0.00 secs: 168 bytes ==> GET /
HTTP/1.1 403 0.00 secs: 168 bytes ==> GET /
HTTP/1.1 403 0.00 secs: 168 bytes ==> GET /
HTTP/1.1 403 0.01 secs: 168 bytes ==> GET /
....
^C
Lifting the server siege...
Transactions: 81 hits
Availability: 100.00 %
Elapsed time: 0.67 secs
Data transferred: 0.01 MB
Response time: 0.00 secs
Transaction rate: 120.90 trans/sec
Throughput: 0.02 MB/sec
Concurrency: 0.39
Successful transactions: 0
Failed transactions: 0
Longest transaction: 0.02
Shortest transaction: 0.00
The Failed transactions field shows zero failed transactions, but this is wrong with regard to manual:
Failed transactions
The number of times the server responded with a return code >= 400
plus the sum of all failed socket transactions which includes
socket timeouts.
Or maybe manual is wrong here?
Can I change the request parameters when running test use siege
Can I change the request parameters when running test use siege?
For example, normally my urllist.txt will like this:
http://127.0.0.1/test POST < params.txt
And my params.txt may like this:
{"name": "Winny"}
Now my problem is how can I change the value of name when running my test?
Segmentation fault for concurrent > 1
This is related in part to my PR #42. Once I did get siege built in the docker-alpine base, when I ran siege with more than 1 concurrent users it would seg fault. I tried using gdb to get the backtrace (bt or where), but no trace was available. When I tried using the debian:jessie docker image as the base, I could use apt-get install siege (no build needed) and that worked just fine.
To recreate the segmentation fault:
- docker run --rm -it alpine sh
- Add the build dependencies: apk add --update alpine-sdk
- wget http://download.joedog.org/siege/siege-latest.tar.gz
- tar -zxvf siege-latest.tar.gz
- cd siege-3.1.3
- ./configure
- Add #include <sys/types.h> below line 24 of src/hash.c
- make
- Run the following: siege -r 1 -c 2 www.google.com
SNI support
Hi there, are there any plans to support SNI https endpoints?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.