- Apache Ab Test
- Apache Ab Load Testing
- Apache Ab Post
- Apache Ab Download
- Apache Ab Test
- Apache Bench Ab
- Apache Ab Testing Examples
Name
- Apache Bench or ab for short, is a command-line tool to perform simple load tests on an HTTP server, be it a website or an API. By running the following command, you will get an overview of how the server is performing under load: ab -n 100 -c 10 So, in this post, I will try to explain how we can use Apache Bench.
- Ab is a tool for benchmarking your Apache Hypertext Transfer Protocol (HTTP) server. It is designed to give you an impression of how your current Apache installation performs. This especially shows you how many requests per second your Apache installation is capable of serving.
- But as you have also set -k for keepalives ab is expecting to reuse those 50 connections, but apache will force close the keepalive if it is idle for 5 seconds. So there might be some odd interaction causing that. Try it without -k setting and see what happens, also try the -r flag to ab with -v set to 3 or 4, as without -r ab is exiting on the.
- This is a simple tool (Non-GUI) for load testing by Apache. You have to first install apache benchmark by (on linux). Sudo apt install apache2-utils Since we want to send a JSON body, we have to.
Ab is a benchmarking tool for web server that normally comes standard with Apache installation. It's used for load-testing your web server and produce useful metrics such as the number of requests per second that the server is able to serve. Ab could be used to.
ab - Apache HTTP server benchmarking toolSynopsis
Apache Ab Test
ab [ -Aauth-username:password ] [ -bwindowsize ] [ -cconcurrency ] [ -Ccookie-name=value ] [ -d ] [ -ecsv-file ] [ -fprotocol ] [ -ggnuplot-file ] [ -h ] [-Hcustom-header ] [ -i ] [ -k ] [ -nrequests ] [ -pPOST-file ] [ -Pproxy-auth-username:password ] [ -q ] [ -r ] [ -s ] [ -S ] [ -ttimelimit ] [ -Tcontent-type ] [ -uPUT-file ] [ -vverbosity] [ -V ] [ -w ] [ -x<table>-attributes ] [-Xproxy[:port] ] [ -y<tr>-attributes ] [ -z<td>-attributes ] [ -Zciphersuite ][http[s]://]hostname[:port]/path
Summary
ab is a tool for benchmarking your Apache Hypertext Transfer Protocol (HTTP) server. It is designed to give you an impression of how your current Apacheinstallation performs. This especially shows you how many requests per second your Apache installation is capable of serving.
Options
- -e csv-file
- Write a Comma separated value (CSV) file which contains for each percentage (from 1% to 100%) the time (in milliseconds) it took to serve that percentageof the requests. This is usually more useful than the 'gnuplot' file; as the results are already 'binned'.
- -f protocol
- Specify SSL/TLS protocol (SSL2, SSL3, TLS1, or ALL).
- -g gnuplot-file
- Write all measured values out as a 'gnuplot' or TSV (Tab separate values) file. This file can easily be imported into packages like Gnuplot, IDL,Mathematica, Igor or even Excel. The labels are on the first line of the file.
- -h
- Display usage information.
- -H custom-header
- Append extra headers to the request. The argument is typically in the form of a valid header line, containing a colon-separated field-value pair(i.e., 'Accept-Encoding: zip/zop;8bit').
- -i
- Do HEAD requests instead of GET.
- -k
- Enable the HTTP KeepAlive feature, i.e., perform multiple requests within one HTTP session. Default is no KeepAlive.
- -n requests
- Number of requests to perform for the benchmarking session. The default is to just perform a single request which usually leads to non-representativebenchmarking results.
- -p POST-file
- File containing data to POST. Remember to also set -T.
- -P proxy-auth-username:password
- Supply BASIC Authentication credentials to a proxy en-route. The username and password are separated by a single : and sent on the wire base64 encoded. Thestring is sent regardless of whether the proxy needs it (i.e., has sent an 407 proxy authentication needed).
- -q
- When processing more than 150 requests, ab outputs a progress count on stderr every 10% or 100 requests or so. The -q flag will suppress these messages.
- -r
- Don't exit on socket receive errors.
- -s
- When compiled in (ab -h will show you) use the SSL protected https rather than the http protocol. This feature is experimental and veryrudimentary. You probably do not want to use it.
- -S
- Do not display the median and standard deviation values, nor display the warning/error messages when the average and median are more than one or two timesthe standard deviation apart. And default to the min/avg/max values. (legacy support).
- -t timelimit
- Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally. Use this to benchmark the server within a fixed total amount oftime. Per default there is no timelimit.
- -T content-type
- Content-type header to use for POST/PUT data, eg. application/x-www-form-urlencoded. Default: text/plain.
- -u PUT-file
- File containing data to PUT. Remember to also set -T.
- -v verbosity
- Set verbosity level - 4 and above prints information on headers, 3 and above prints response codes (404, 200, etc.), 2 and above prints warnings and info.
- -V
- Display version number and exit.
- -w
- Print out results in HTML tables. Default table is two columns wide, with a white background.
- -x <table>-attributes
- String to use as attributes for <table>. Attributes are inserted <table here >.
- -X proxy[:port]
- Use a proxy server for the requests.
- -y <tr>-attributes
- String to use as attributes for <tr>.
- -z <td>-attributes
- String to use as attributes for <td>.
- -Z ciphersuite
- Specify SSL/TLS cipher suite (See openssl ciphers).
Bugs
There are various statically declared buffers of fixed length. Combined with the lazy parsing of the command line arguments, the response headers from theserver and other external inputs, this might bite you.
It does not implement HTTP/1.x fully; only accepts some 'expected' forms of responses. The rather heavy use of strstr(3) shows up top in profile,which might indicate a performance problem; i.e., you would measure the ab performance rather than the server's.
Tutorial
Introduction
Load testing is a good idea before any deployment. Although it’s not something to be skimped out on, sometimes it’s nice to quickly establish a best-case scenario for a project before running more detailed tests down the road.
The ApacheBench tool (ab) can load test servers by sending an arbitrary number of concurrent requests. Although ab was designed for testing Apache installations, it can be used to benchmark any HTTP server.
In this tutorial, we will see how a Ruby interpreter with different servers performs under load. The tutorial steps assume a fresh Arch Linux x86_64 image. The results were obtained from a 512 MB droplet.
Installation
Refresh the package database.
Install the apache package to get access to ApacheBench. Alternatively, it is contained in the apache-tools package in the AUR.
Limited Privilege User
Next, create the user that will manage Ruby. It’s not a good idea to run some of the commands in the next section as root.
Apache Ab Load Testing
Switch to the new user.
RVM
The Ruby Version Manager makes it easy to work with different Ruby environments. It takes care of the process of installing specific Ruby versions and isolating gemsets. It is currently installed by running a bash script from their website.
In order to use the rvm command, you need to first run the rvm script.
Next, install Ruby 2.0.0. RVM generally builds Ruby from source, so this step may take a while.
Switch to the new Ruby. This might happen by default after the installation, but checking doesn’t hurt.
Testing
Apache Ab Post
Now that Ruby is installed, you can create a simple site and see how many requests it can handle.
Install Sinatra. It’s a microframework/DSL for creating Ruby web applications. The –no-* flags skip the documentation.
Create the sample sinatra app which just echoes “hello world”.
Run the server.
With the server finally up, you can start load testing. A call to ab looks like this:
Open another terminal and ssh into the server again. Run a test with ApacheBench. I used 1000 requests with a concurrency of 100. Don’t forget the final ’/’ at the end for the path.
Apache Ab Download
My results converged around 300 requests/second. WEBrick is not known for its speed. Go ahead and interrupt the server with Ctrl-c.
Apache Ab Test
Thin is a popular ruby web server that uses Mongrel for parsing and EventMachine for non-blocking IO. Install Thin and run the server again. Sinatra should load Thin automatically and let you know (“…with backup from Thin”).
Apache Bench Ab
Now, try the load test again. It should be a bit faster this time.
Note: Thin does not appear to allow ApacheBench connections via localhost, but it allows 0.0.0.0 or 127.0.0.1.
At least in this case, it looks like Thin makes for a notably faster server than WEBrick at over 1000 requests/second (You can try raising the total requests, but it didn’t get much higher for me). Not bad.
Conclusion
Obviously, these results do not reflect realistic server performance. HTTP is just one piece of the puzzle. A slow templating engine and/or database will drag these numbers down significantly. Still, it gives you a quick ballpark figure for comparison.
Other performance tools you might be interested in:
Apache Ab Testing Examples
<div class=“author”>Submitted by: <a href=“http://robertqualls.com”>Robert Qualls</a></div>