Last 30 days

• Feb 03, 2012

  issue 8 (Extending SSL support) commented on by Neo8...@gmail.com   -   I would love to see these changes merged. Is there a blocker?

  I would love to see these changes merged. Is there a blocker?

Older

• Dec 15, 2011

  issue 11 (Error: Use of uninitialized value in concatenation) commented on by olivier....@gmail.com   -   Getting the same error on OS X 10.7.2. Is this project still being developed? Use of uninitialized value $results{"replies"} in numeric eq (==) at /usr/local/bin/autobench line 184. Zero replies received, test invalid: rate 50 Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308.

  Getting the same error on OS X 10.7.2. Is this project still being developed? Use of uninitialized value $results{"replies"} in numeric eq (==) at /usr/local/bin/autobench line 184. Zero replies received, test invalid: rate 50 Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308.
• Nov 11, 2011

  issue 1 (User-Agent is static) commented on by chekhyn   -   I have httperf-0.9.0 anb try to apply the patch like this patch -p0 <enable_custom_http_headers-v3.patch but I'v got the following: patching file configure.ac Hunk #1 succeeded at 10 with fuzz 2 (offset -73 lines). patching file src/httperf.c Hunk #1 FAILED at 114. Hunk #2 FAILED at 176. Hunk #3 FAILED at 1063. 3 out of 3 hunks FAILED -- saving rejects to file src/httperf.c.rej patching file src/call.h Hunk #1 succeeded at 42 with fuzz 1 (offset 5 lines). patching file src/httperf.h Hunk #1 succeeded at 136 with fuzz 1 (offset 14 lines). patching file src/gen/uri_wlog.c Hunk #2 succeeded at 91 (offset -5 lines). Hunk #3 succeeded at 172 (offset -5 lines). patching file src/core.c Hunk #1 succeeded at 118 with fuzz 2 (offset 27 lines). Hunk #2 FAILED at 146. Hunk #3 FAILED at 980. Hunk #4 FAILED at 997. Hunk #5 FAILED at 1004. 4 out of 5 hunks FAILED -- saving rejects to file src/core.c.rej patching file man/httperf.1 Hunk #1 FAILED at 13. Hunk #2 FAILED at 196. 2 out of 2 hunks FAILED -- saving rejects to file man/httperf.1.rej What do I do wrong?

  I have httperf-0.9.0 anb try to apply the patch like this patch -p0 <enable_custom_http_headers-v3.patch but I'v got the following: patching file configure.ac Hunk #1 succeeded at 10 with fuzz 2 (offset -73 lines). patching file src/httperf.c Hunk #1 FAILED at 114. Hunk #2 FAILED at 176. Hunk #3 FAILED at 1063. 3 out of 3 hunks FAILED -- saving rejects to file src/httperf.c.rej patching file src/call.h Hunk #1 succeeded at 42 with fuzz 1 (offset 5 lines). patching file src/httperf.h Hunk #1 succeeded at 136 with fuzz 1 (offset 14 lines). patching file src/gen/uri_wlog.c Hunk #2 succeeded at 91 (offset -5 lines). Hunk #3 succeeded at 172 (offset -5 lines). patching file src/core.c Hunk #1 succeeded at 118 with fuzz 2 (offset 27 lines). Hunk #2 FAILED at 146. Hunk #3 FAILED at 980. Hunk #4 FAILED at 997. Hunk #5 FAILED at 1004. 4 out of 5 hunks FAILED -- saving rejects to file src/core.c.rej patching file man/httperf.1 Hunk #1 FAILED at 13. Hunk #2 FAILED at 196. 2 out of 2 hunks FAILED -- saving rejects to file man/httperf.1.rej What do I do wrong?
• Sep 11, 2011

  issue 12 (Using --wlog file causes "httperf.parse_status_line: invalid...) commented on by mikeh...@gmail.com   -   I figured it out, it is not a defect, the problem is that the wlog file is not formatted correctly. Each line must terminate with '\0' inestead of '\n'

  I figured it out, it is not a defect, the problem is that the wlog file is not formatted correctly. Each line must terminate with '\0' inestead of '\n'
• Sep 09, 2011

  issue 12 (Using --wlog file causes "httperf.parse_status_line: invalid...) commented on by mikeh...@gmail.com   -   I have run into this problem, is somebody going to get to this but any time soon?

  I have run into this problem, is somebody going to get to this but any time soon?
• Aug 12, 2011

  issue 15 (--hog option should set the address family before binding th...) reported by cyril.bo...@free.fr   -   Using httperf with --hog option can prevent it binding sockets because the socket family is not set. $ strace -tt httperf --hog ... 00:29:42.668802 bind(3, {sa_family=AF_UNSPEC, sa_data="PY\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668839 bind(3, {sa_family=AF_UNSPEC, sa_data="PZ\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668877 bind(3, {sa_family=AF_UNSPEC, sa_data="P[\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668914 bind(3, {sa_family=AF_UNSPEC, sa_data="P\\\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668950 bind(3, {sa_family=AF_UNSPEC, sa_data="P]\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668988 bind(3, {sa_family=AF_UNSPEC, sa_data="P^\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.669025 bind(3, {sa_family=AF_UNSPEC, sa_data="P_\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) ... $ uname -a Linux ... 3.0.0-8-generic #10-Ubuntu SMP Fri Aug 5 23:54:15 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux The small patch attached sets the family to AF_INET.

  Using httperf with --hog option can prevent it binding sockets because the socket family is not set. $ strace -tt httperf --hog ... 00:29:42.668802 bind(3, {sa_family=AF_UNSPEC, sa_data="PY\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668839 bind(3, {sa_family=AF_UNSPEC, sa_data="PZ\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668877 bind(3, {sa_family=AF_UNSPEC, sa_data="P[\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668914 bind(3, {sa_family=AF_UNSPEC, sa_data="P\\\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668950 bind(3, {sa_family=AF_UNSPEC, sa_data="P]\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.668988 bind(3, {sa_family=AF_UNSPEC, sa_data="P^\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) 00:29:42.669025 bind(3, {sa_family=AF_UNSPEC, sa_data="P_\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = -1 EAFNOSUPPORT (Address family not supported by protocol) ... $ uname -a Linux ... 3.0.0-8-generic #10-Ubuntu SMP Fri Aug 5 23:54:15 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux The small patch attached sets the family to AF_INET.
• Aug 02, 2011

  issue 10 (enormous number of CLOSE_WAIT ) commented on by gcorrao....@gmail.com   -   I'm having the same problem. What are you testing against? I'm benchmarking Varnish 3.0, also in Ubuntu Server 10.04. Don't know if that may be relevant.

  I'm having the same problem. What are you testing against? I'm benchmarking Varnish 3.0, also in Ubuntu Server 10.04. Don't know if that may be relevant.
• Jul 19, 2011

  issue 14 (Add headers to sessions in wsesslog) reported by PhiSIg...@gmail.com   -   The wsesslog file has no option to add http headers to individual requests. Attached is a patch that will allow up to 16k of arbitrary headers to be added. Example usage: # session 1 definition (this is a comment) /foo.html think=2.0 headers='Cookie: CO=blahblahblah;' /pict1.gif /pict2.gif /foo2.html method=POST contents='Post data' headers='Cookie: CO=foo;' /pict3.gif /pict4.gif Based on the patch from http://www.overset.com/2008/03/27/load-test-ajax-applications-with-httperf/ but with modest improvements.

  The wsesslog file has no option to add http headers to individual requests. Attached is a patch that will allow up to 16k of arbitrary headers to be added. Example usage: # session 1 definition (this is a comment) /foo.html think=2.0 headers='Cookie: CO=blahblahblah;' /pict1.gif /pict2.gif /foo2.html method=POST contents='Post data' headers='Cookie: CO=foo;' /pict3.gif /pict4.gif Based on the patch from http://www.overset.com/2008/03/27/load-test-ajax-applications-with-httperf/ but with modest improvements.
• Jun 04, 2011

  issue 13 (Typo in manpage) reported by m.fellin...@gmail.com   -   What steps will reproduce the problem? 1. MANWIDTH=70 man httperf | awk '{ if(FNR == 13 || FNR == 46){ print $NL } }' What is the expected output? What do you see instead? Expected: calls N] [--num-conns N] [--period [d|u|e]T1[,T2]] [--port N] httperf --hog --server www --num-conns 100 --ra 10 --timeout 5 Actual: calls N] [--num-conns N] [--period [d|u|e]T1[,T2]] [--port N] httperf --hog --server www --num-conn 100 --ra 10 --timeout 5 What version of the product are you using? On what operating system? 0.9.0 on Archlinux Please provide any additional information below. This might be a way to fix it: sed -i 's/conn /conns /'

  What steps will reproduce the problem? 1. MANWIDTH=70 man httperf | awk '{ if(FNR == 13 || FNR == 46){ print $NL } }' What is the expected output? What do you see instead? Expected: calls N] [--num-conns N] [--period [d|u|e]T1[,T2]] [--port N] httperf --hog --server www --num-conns 100 --ra 10 --timeout 5 Actual: calls N] [--num-conns N] [--period [d|u|e]T1[,T2]] [--port N] httperf --hog --server www --num-conn 100 --ra 10 --timeout 5 What version of the product are you using? On what operating system? 0.9.0 on Archlinux Please provide any additional information below. This might be a way to fix it: sed -i 's/conn /conns /'
• May 02, 2011

  issue 10 (enormous number of CLOSE_WAIT ) commented on by duffle...@gmail.com   -   I have the same problem. Around 1000 open CLOSE_WAIT sockets. httperf waits with no traffic until killed. httperf-0.9.0-6.fc12.x86_64 rpm on 2.6.34.8-68.fc13.x86_64.

  I have the same problem. Around 1000 open CLOSE_WAIT sockets. httperf waits with no traffic until killed. httperf-0.9.0-6.fc12.x86_64 rpm on 2.6.34.8-68.fc13.x86_64.
• Feb 20, 2011

  r140 (Remove boilerplate text from bottom of copyright file since ...) committed by tbull...@comlore.com   -   Remove boilerplate text from bottom of copyright file since it isn't quite applicable to httperf

  Remove boilerplate text from bottom of copyright file since it isn't quite applicable to httperf
• Feb 20, 2011

  r140 (Remove boilerplate text from bottom of copyright file since ...) committed by tbull...@comlore.com   -   Remove boilerplate text from bottom of copyright file since it isn't quite applicable to httperf

  Remove boilerplate text from bottom of copyright file since it isn't quite applicable to httperf
• Feb 16, 2011

  r139 (Portablelize new getopt.c so it should work where err.h is m...) committed by tbull...@comlore.com   -   Portablelize new getopt.c so it should work where err.h is missing

  Portablelize new getopt.c so it should work where err.h is missing
• Feb 16, 2011

  r139 (Portablelize new getopt.c so it should work where err.h is m...) committed by tbull...@comlore.com   -   Portablelize new getopt.c so it should work where err.h is missing

  Portablelize new getopt.c so it should work where err.h is missing
• Feb 10, 2011

  r138 (Remove anjuta conf stuff) committed by tbull...@comlore.com   -   Remove anjuta conf stuff

  Remove anjuta conf stuff
• Feb 10, 2011

  r138 (Remove anjuta conf stuff) committed by tbull...@comlore.com   -   Remove anjuta conf stuff

  Remove anjuta conf stuff
• Feb 10, 2011

  r137 (Adjust copyright text to clearly mark copyright owners) committed by tbull...@comlore.com   -   Adjust copyright text to clearly mark copyright owners

  Adjust copyright text to clearly mark copyright owners
• Feb 10, 2011

  r137 (Adjust copyright text to clearly mark copyright owners) committed by tbull...@comlore.com   -   Adjust copyright text to clearly mark copyright owners

  Adjust copyright text to clearly mark copyright owners
• Feb 10, 2011

  r136 (Removed duplicate version of gpl, besides getopt was the rea...) committed by tbull...@comlore.com   -   Removed duplicate version of gpl, besides getopt was the reason the file was there to begin with and it is now supplied by a different vendor

  Removed duplicate version of gpl, besides getopt was the reason the file was there to begin with and it is now supplied by a different vendor
• Feb 10, 2011

  r136 (Removed duplicate version of gpl, besides getopt was the rea...) committed by tbull...@comlore.com   -   Removed duplicate version of gpl, besides getopt was the reason the file was there to begin with and it is now supplied by a different vendor

  Removed duplicate version of gpl, besides getopt was the reason the file was there to begin with and it is now supplied by a different vendor
• Feb 10, 2011

  r135 (replace bundled, out of date getopt with version from openbs...) committed by tbull...@comlore.com   -   replace bundled, out of date getopt with version from openbsd

  replace bundled, out of date getopt with version from openbsd
• Feb 10, 2011

  r135 (replace bundled, out of date getopt with version from openbs...) committed by tbull...@comlore.com   -   replace bundled, out of date getopt with version from openbsd

  replace bundled, out of date getopt with version from openbsd
• Feb 07, 2011

  r134 (Cleaned up help text) committed by tbull...@comlore.com   -   Cleaned up help text

  Cleaned up help text
• Feb 07, 2011

  r134 (Cleaned up help text) committed by tbull...@comlore.com   -   Cleaned up help text

  Cleaned up help text
• Feb 07, 2011

  r133 (Cleaned up help text) committed by tbull...@comlore.com   -   Cleaned up help text

  Cleaned up help text
• Feb 07, 2011

  r133 (Cleaned up help text) committed by tbull...@comlore.com   -   Cleaned up help text

  Cleaned up help text
• Jan 13, 2011

  issue 12 (Using --wlog file causes "httperf.parse_status_line: invalid...) reported by dlbroome   -   What steps will reproduce the problem? 1. Create a wlog uri file with a forward slash in it 2. Issue a single request against yahoo.com (as an example only): httperf --server=www.yahoo.com --wlog=n,uri.txt --rate=1 --num-conns=1 --num-calls=1 --print-request --print-reply=header What is the expected output? What do you see instead? I would expect to see results, but instead I see the above error What version of the product are you using? On what operating system? 0.9.0, ubuntu 10 Please provide any additional information below. When issuing the above command, the request headers have the "HTTP/1.1" on a second line as opposed to the first line. The web server returns no status lines when this happens. If you issue the same test with the --uri parameter instead of --wlog: httperf --server=www.yahoo.com --uri=/ --num-conns=1 --num-calls=1 rate=1 --print-request --print-reply=header then the test succeeds as expected. Here is the comparison between the request headers between the two requests: SH0:GET / SH0: HTTP/1.1 SH0:User-Agent: httperf/0.9.0 SH0:Host: www.yahoo.com SH0: SS0: header 67 content 0 SH0:GET / HTTP/1.1 SH0:User-Agent: httperf/0.9.0 SH0:Host: www.yahoo.com SH0: SS0: header 66 content 0 and the difference in the reply headers, the first causing the error: RH0:<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" RH0: "http://www.w3.org/TR/html4/strict.dtd"> RH0:<html lang="en-US" class="y-fp-bg y-fp-pg-grad bkt701"> RH0:HTTP/1.1 200 OK RH0:Date: Thu, 13 Jan 2011 20:12:28 GMT ...

  What steps will reproduce the problem? 1. Create a wlog uri file with a forward slash in it 2. Issue a single request against yahoo.com (as an example only): httperf --server=www.yahoo.com --wlog=n,uri.txt --rate=1 --num-conns=1 --num-calls=1 --print-request --print-reply=header What is the expected output? What do you see instead? I would expect to see results, but instead I see the above error What version of the product are you using? On what operating system? 0.9.0, ubuntu 10 Please provide any additional information below. When issuing the above command, the request headers have the "HTTP/1.1" on a second line as opposed to the first line. The web server returns no status lines when this happens. If you issue the same test with the --uri parameter instead of --wlog: httperf --server=www.yahoo.com --uri=/ --num-conns=1 --num-calls=1 rate=1 --print-request --print-reply=header then the test succeeds as expected. Here is the comparison between the request headers between the two requests: SH0:GET / SH0: HTTP/1.1 SH0:User-Agent: httperf/0.9.0 SH0:Host: www.yahoo.com SH0: SS0: header 67 content 0 SH0:GET / HTTP/1.1 SH0:User-Agent: httperf/0.9.0 SH0:Host: www.yahoo.com SH0: SS0: header 66 content 0 and the difference in the reply headers, the first causing the error: RH0:<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" RH0: "http://www.w3.org/TR/html4/strict.dtd"> RH0:<html lang="en-US" class="y-fp-bg y-fp-pg-grad bkt701"> RH0:HTTP/1.1 200 OK RH0:Date: Thu, 13 Jan 2011 20:12:28 GMT ...
• Dec 19, 2010

  issue 11 (Error: Use of uninitialized value in concatenation) reported by black.sorcerer   -   I installed httperf on my MBP running Mac OSX 10.6.4 Installed httperf and autobench. When I executed the command: autobench --single_host --host1 google.com --uri1 / --low_rate 5 --high_rate 20 --rate_step 10 --num_call 10 Below is the error result: Zero replies received, test invalid: rate 15 Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308.

  I installed httperf on my MBP running Mac OSX 10.6.4 Installed httperf and autobench. When I executed the command: autobench --single_host --host1 google.com --uri1 / --low_rate 5 --high_rate 20 --rate_step 10 --num_call 10 Below is the error result: Zero replies received, test invalid: rate 15 Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/autobench line 308.
• Oct 06, 2010

  issue 9 (Addition to set source address) commented on by ejaz9645   -   is it possible for you to give the example of how to use it. IT seems not working. Cheers

  is it possible for you to give the example of how to use it. IT seems not working. Cheers
• Sep 27, 2010

  issue 1 (User-Agent is static) commented on by daveviner   -   Sorry.. forgot to update the man page to include a note about embedded-http-headers

  Sorry.. forgot to update the man page to include a note about embedded-http-headers
• Sep 27, 2010

  issue 1 (User-Agent is static) commented on by daveviner   -   Slightly improved patch. strnstr is not portable, but rather it's FreeBSD specific. So here's a simple version that checks to see if strnstr is available. If not, we use a basic implementation.

  Slightly improved patch. strnstr is not portable, but rather it's FreeBSD specific. So here's a simple version that checks to see if strnstr is available. If not, we use a basic implementation.
• Sep 26, 2010

  issue 1 (User-Agent is static) commented on by daveviner   -   Here's a patch that actually solves this problem, as it relates to the use of wlog files. I added a new command-line option, called --embedded-http-headers. Invoking httperf with this option allows you to create slightly different wlog files for invoking lots of urls. In 0.9.0, the wlog file format is a null-delimited list of URLs to request. If you invoke with --embedded-http-headers, you can specify per-URL http headers in the file. The format of the file is still null-delimited. However, within each URL, you may (optionally) add HTTP headers, separated from the URL by a control-A character. So, the line format looks like: custom-header-1: foo\ncustom-header-2: bar\n^A/index.html\0 custom-header-3: baz\ncustom-header-4: quux\n^A/someother/page.html\0 The HTTP headers are specific to each URL requested (they are not additive). This patch solves the user-agent problem when using a custom log file to replay large numbers of requests.

  Here's a patch that actually solves this problem, as it relates to the use of wlog files. I added a new command-line option, called --embedded-http-headers. Invoking httperf with this option allows you to create slightly different wlog files for invoking lots of urls. In 0.9.0, the wlog file format is a null-delimited list of URLs to request. If you invoke with --embedded-http-headers, you can specify per-URL http headers in the file. The format of the file is still null-delimited. However, within each URL, you may (optionally) add HTTP headers, separated from the URL by a control-A character. So, the line format looks like: custom-header-1: foo\ncustom-header-2: bar\n^A/index.html\0 custom-header-3: baz\ncustom-header-4: quux\n^A/someother/page.html\0 The HTTP headers are specific to each URL requested (they are not additive). This patch solves the user-agent problem when using a custom log file to replay large numbers of requests.
• Aug 16, 2010

  issue 8 (Extending SSL support) commented on by dan.carley   -   Great work, thanks. Also working fine against Nginx.

  Great work, thanks. Also working fine against Nginx.
• Aug 11, 2010

  issue 10 (enormous number of CLOSE_WAIT ) reported by xrfang   -   -- What steps will reproduce the problem? run the following command: httperf --hog --rate=500 --num-conns=200000 --timeout=5 --uri=/img/default.jpeg --num-calls=10 --server=svr-web -- What is the expected output? What do you see instead? The test shall be finished within about 400 seconds (200000 / 500), but it get stuck. After a while, I found that there is no network traffic from client to server, and netstat shows that there are more than 1000 sockets in CLOSE_WAIT state. Note that if I use --num-conns with a smaller number, e.g. 20000, there is no problem at all. I guess this is a problem in httperf on handling socket close operation? -- What version of the product are you using? On what operating system? Ubuntu 10.04 (both server and client) on Q8400 with 4G memory. Note that the server is also running on a desktop (gnome) version of ubuntu, not server edition. Also I have tuned file descriptor limit on the client and compiled httperf on it.

  -- What steps will reproduce the problem? run the following command: httperf --hog --rate=500 --num-conns=200000 --timeout=5 --uri=/img/default.jpeg --num-calls=10 --server=svr-web -- What is the expected output? What do you see instead? The test shall be finished within about 400 seconds (200000 / 500), but it get stuck. After a while, I found that there is no network traffic from client to server, and netstat shows that there are more than 1000 sockets in CLOSE_WAIT state. Note that if I use --num-conns with a smaller number, e.g. 20000, there is no problem at all. I guess this is a problem in httperf on handling socket close operation? -- What version of the product are you using? On what operating system? Ubuntu 10.04 (both server and client) on Q8400 with 4G memory. Note that the server is also running on a desktop (gnome) version of ubuntu, not server edition. Also I have tuned file descriptor limit on the client and compiled httperf on it.
• Jun 04, 2010

  issue 9 (Addition to set source address) reported by l...@581.spb.su   -   It is useful to set arbitrary source address when benchmarking some configurations. I've made a quick patch (no docs, source code only, sorry).

  It is useful to set arbitrary source address when benchmarking some configurations. I've made a quick patch (no docs, source code only, sorry).
• May 06, 2010

  issue 8 (Extending SSL support) commented on by rowan.littell   -   Note - not a "defect" but an enhancement.

  Note - not a "defect" but an enhancement.
• May 06, 2010

  issue 8 (Extending SSL support) reported by rowan.littell   -   Currently httperf v0.9.0 does not support SSL client certificate authentication, server certificate verification, or choosing the SSL protocol version. This patch adds the following: 1) Client SSL certificate authentication - add --ssl-certificate option (required argument file name) to specify the certificate - add --ssl-key option (required argument file name) to specify the key - loads certificate and key into the SSL context and performs a consistency check 2) Server certificate verification - add --ssl-verify option (optional arguments "no" and "yes") to control verification (off by default) - add --ssl-ca-file and --ssl-ca-path options (required arguments file and path names) to set custom certificate authority file and path - load system default certificate path (e.g., /etc/ssl/certs) 3) Choose SSL protocol version - add --ssl-protocol option (required argument of "auto", "SSLv2", "SSLv3", or "TLSv1") to choose protocol; "auto" (default) chooses SSLv23_client_method The patch modifies httperf.h and httperf.c, adding the appropriate option processing and OpenSSL code, as well as reporting these options in help text (--help) and the command line summary when running the program. It has been tested on MacOS X (10.4), Ubuntu 9.04, and Solaris 10 x86 using gcc3. It is known to operate properly against Apache 2.2/mod_ssl, pound, and Ruby WEBrick servers. Note: this changes the default SSL protocol from SSLv3_client_method to SSLv23_client_method. Other new options (e.g. --ssl-verify) are off by default.

  Currently httperf v0.9.0 does not support SSL client certificate authentication, server certificate verification, or choosing the SSL protocol version. This patch adds the following: 1) Client SSL certificate authentication - add --ssl-certificate option (required argument file name) to specify the certificate - add --ssl-key option (required argument file name) to specify the key - loads certificate and key into the SSL context and performs a consistency check 2) Server certificate verification - add --ssl-verify option (optional arguments "no" and "yes") to control verification (off by default) - add --ssl-ca-file and --ssl-ca-path options (required arguments file and path names) to set custom certificate authority file and path - load system default certificate path (e.g., /etc/ssl/certs) 3) Choose SSL protocol version - add --ssl-protocol option (required argument of "auto", "SSLv2", "SSLv3", or "TLSv1") to choose protocol; "auto" (default) chooses SSLv23_client_method The patch modifies httperf.h and httperf.c, adding the appropriate option processing and OpenSSL code, as well as reporting these options in help text (--help) and the command line summary when running the program. It has been tested on MacOS X (10.4), Ubuntu 9.04, and Solaris 10 x86 using gcc3. It is known to operate properly against Apache 2.2/mod_ssl, pound, and Ruby WEBrick servers. Note: this changes the default SSL protocol from SSLv3_client_method to SSLv23_client_method. Other new options (e.g. --ssl-verify) are off by default.
• Apr 07, 2010

  issue 7 (Contribution) reported by Xerrot   -   My name is Christopher Torres, I'm an undergraduate student at the University of Puerto at Bayamon. Currently I'm involved on an undergraduate research initiative lead by Dr. Juan Sola Sloan (http://www.uprb.edu/profesor/jsola/) working on httperf. Our current goal is to provide functionality that allows dumping test results into a file for further performance analysis. Another fellow student is working on a tool that uses this file as input and generates some cool graphs in a webpage. How can we contribute to the whole httperf project with our findings? Thank you for your time, Christopher Torres xerrot at gmail dot com

  My name is Christopher Torres, I'm an undergraduate student at the University of Puerto at Bayamon. Currently I'm involved on an undergraduate research initiative lead by Dr. Juan Sola Sloan (http://www.uprb.edu/profesor/jsola/) working on httperf. Our current goal is to provide functionality that allows dumping test results into a file for further performance analysis. Another fellow student is working on a tool that uses this file as input and generates some cool graphs in a webpage. How can we contribute to the whole httperf project with our findings? Thank you for your time, Christopher Torres xerrot at gmail dot com
• Jan 13, 2010

  issue 3 (--no-host-hdr option doesn't work with --add-header) commented on by nicolas.van.eenaeme   -   I had the same issue and I created a small patch to fix this. Note, the headers you add must end with the newline character, otherwise the request won't be valid and the program keeps hanging. This is a really quick&dirty fix but it works for me. Cheers, Nicolas

  I had the same issue and I created a small patch to fix this. Note, the headers you add must end with the newline character, otherwise the request won't be valid and the program keeps hanging. This is a really quick&dirty fix but it works for me. Cheers, Nicolas
• Dec 16, 2009

  issue 6 (Default server and URI) reported by tbull...@comlore.com   -   I don't think it makes sense to assume that the server is "localhost" and the URI is "/" if they're not supplied on the command line; perf testing the same box as you run the clients on is bad practice. Instead, these arguments (or a suitable logfile generator) should be required, and httperf should fail if it can't find an explicit specification of the test URI.

  I don't think it makes sense to assume that the server is "localhost" and the URI is "/" if they're not supplied on the command line; perf testing the same box as you run the clients on is bad practice. Instead, these arguments (or a suitable logfile generator) should be required, and httperf should fail if it can't find an explicit specification of the test URI.
• Dec 16, 2009

  issue 5 (repeating content in --print-reply) reported by tbull...@comlore.com   -   If you specify --print-reply and the response body is large, the headers will print repeatedly as the content streams out. I think this is because print_reply() is called every time send_raw_data fires. E.g., SH0:PUT /test.jpg HTTP/1.1 SH0:Host: www.example.net SH0:Content-Type: image/jpeg SH0:Content-Length: 55672 SH0:User-Agent: httperf/0.9.0 SH0: SS0: header 148 content 55672 SH0:PUT /test.jpg HTTP/1.1 SH0:Host: www.example.net SH0:Content-Type: image/jpeg SH0:Content-Length: 55672 SH0:User-Agent: httperf/0.9.0 SH0: SS0: header 148 content 51476 SH0:PUT /test.jpg HTTP/1.1 SH0:Host: www.example.net SH0:Content-Type: image/jpeg SH0:Content-Length: 55672 SH0:User-Agent: httperf/0.9.0 SH0:

  If you specify --print-reply and the response body is large, the headers will print repeatedly as the content streams out. I think this is because print_reply() is called every time send_raw_data fires. E.g., SH0:PUT /test.jpg HTTP/1.1 SH0:Host: www.example.net SH0:Content-Type: image/jpeg SH0:Content-Length: 55672 SH0:User-Agent: httperf/0.9.0 SH0: SS0: header 148 content 55672 SH0:PUT /test.jpg HTTP/1.1 SH0:Host: www.example.net SH0:Content-Type: image/jpeg SH0:Content-Length: 55672 SH0:User-Agent: httperf/0.9.0 SH0: SS0: header 148 content 51476 SH0:PUT /test.jpg HTTP/1.1 SH0:Host: www.example.net SH0:Content-Type: image/jpeg SH0:Content-Length: 55672 SH0:User-Agent: httperf/0.9.0 SH0:
• Dec 16, 2009

  issue 4 (Connection: close not honoured) reported by tbull...@comlore.com   -   httperf does not recognize "Connection: close" headers, it assumes Web servers that claim to be "HTTP/1.1" to support persistent connections. Likewise, it assumes servers that claim to be "HTTP/1.0" do not support persistent connections. From RFC2616 section 14.10; HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example, Connection: close in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete. HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.

  httperf does not recognize "Connection: close" headers, it assumes Web servers that claim to be "HTTP/1.1" to support persistent connections. Likewise, it assumes servers that claim to be "HTTP/1.0" do not support persistent connections. From RFC2616 section 14.10; HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example, Connection: close in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete. HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.
• Dec 16, 2009

  issue 3 (--no-host-hdr option doesn't work with --add-header) reported by tbull...@comlore.com   -   For my testing, I need to set my own Host header, so I disable the auto-generated Host header with --no-host-hdr and add in my own Host header among other additional headers I need with the --add-header option. With that, the auto-generated Host header is gone, but left with an empty line "\r\n" (see the output with the empty line below), which with another "\r\n" signals end of header section in HTTP. As a result, my own additional headers are treated as the body of the HTTP request and thus ignored. SH0:GET /folder/hello.txt HTTP/1.1 SH0:User-Agent: httperf/0.9.0 SH0: SH0:My-Header: some text SH0:Host: www.mydomain.com SH0:

  For my testing, I need to set my own Host header, so I disable the auto-generated Host header with --no-host-hdr and add in my own Host header among other additional headers I need with the --add-header option. With that, the auto-generated Host header is gone, but left with an empty line "\r\n" (see the output with the empty line below), which with another "\r\n" signals end of header section in HTTP. As a result, my own additional headers are treated as the body of the HTTP request and thus ignored. SH0:GET /folder/hello.txt HTTP/1.1 SH0:User-Agent: httperf/0.9.0 SH0: SH0:My-Header: some text SH0:Host: www.mydomain.com SH0:
• Dec 16, 2009

  issue 2 (Option to abort if there are errors) reported by tbull...@comlore.com   -   For some users, interpreting httperf's output can be difficult. Since a large part of doing so is assuring that the test ran successfully (i.e., there were no client-side errors), it strikes me that it would simplify things considerably if we added a command-line flag that, when present, would instruct httperf to abort with an appropriate complaint if; a) total CPU is less than, say, 90%, or b) any errors *other than* client-timeout are seen This would make it significantly easier for operators to interpret the output. Optionally, if the flag is present and the test run is successful, we could suppress the CPU and error information (perhaps just leaving the total), to make output cleaner.

  For some users, interpreting httperf's output can be difficult. Since a large part of doing so is assuring that the test ran successfully (i.e., there were no client-side errors), it strikes me that it would simplify things considerably if we added a command-line flag that, when present, would instruct httperf to abort with an appropriate complaint if; a) total CPU is less than, say, 90%, or b) any errors *other than* client-timeout are seen This would make it significantly easier for operators to interpret the output. Optionally, if the flag is present and the test run is successful, we could suppress the CPU and error information (perhaps just leaving the total), to make output cleaner.
• Dec 16, 2009

  issue 1 (User-Agent is static) reported by tbull...@comlore.com   -   httperf will always emit the httperf user-agent, even when set explicitly in arguments. This makes it difficult to test when UA is important to the server. Two possible fixes; 1) make it possible to explicitly override the UA on the command line. It would probably also be necessary to allow logs (e.g., wlog) to override it. 2) omit the UA, unless it's specified. #2 is probably easier, but may cause problems if people don't remember to set a UA.

  httperf will always emit the httperf user-agent, even when set explicitly in arguments. This makes it difficult to test when UA is important to the server. Two possible fixes; 1) make it possible to explicitly override the UA on the command line. It would probably also be necessary to allow logs (e.g., wlog) to override it. 2) omit the UA, unless it's specified. #2 is probably easier, but may cause problems if people don't remember to set a UA.
• Dec 16, 2009

  r132 (Mention that httperf has been pulled for the time being ) committed by tbull...@comlore.com   -   Mention that httperf has been pulled for the time being

  Mention that httperf has been pulled for the time being
• Dec 16, 2009

  r131 (Remove libevent port (for now) ) committed by tbull...@comlore.com   -   Remove libevent port (for now)

  Remove libevent port (for now)
• Dec 15, 2009

  r130 (Note Adrian Chadd as libevent port author) committed by tbull...@comlore.com   -   Note Adrian Chadd as libevent port author

  Note Adrian Chadd as libevent port author
• Dec 15, 2009

  r129 (Remove CVS associated files) committed by tbull...@comlore.com   -   Remove CVS associated files

  Remove CVS associated files
• Dec 11, 2009

  httperf-0.4.tar.gz (httperf-0.4) file uploaded by mnotting