Apache Ab Benchmark

1. Apache Ab Benchmark Test
2. Ab Apache Benchmark Example Post
3. Apache Ab Benchmarking
4. Ab Apache Benchmark Https

Name

The apache benchmark tool is very basic, and while it will give you a solid idea of some performance, it is a bad idea to only depend on it if you plan to have your site exposed to serious stress in production. Having said that, here's the most common and simplest parameters. 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 benchmark any web server including Apache. 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. The Apache Bench command-line tool comes bundled with the apache or apache2-utils packages. When Apache is installed on our server, the ab command will be available to benchmark a website. To install ab, run the following command. I try to install Apache Benchmark using Is there a way to install Apache Bench (ab) without installing apache solutions on my centos but when i run yumdownloader httpd, i get error: root@local /.

Synopsis

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.

Introduction

Load testing is a good idea before any deployment. 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 Ubuntu 13.10 x32 image. The results were obtained from a 512 MB droplet.

Installation

Refresh the package database.

Install the apache2-utils package to get access to ApacheBench.

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.

What this command accomplishes:

• useradd - create a new user

• -m - create the home directory

• -d /home/test - set the user’s home directory to /home/test

• -s /bin/bash - make the user’s default shell bash (Ubuntu uses dash by default)

• -g sudo - add user to the sudo group (for running commands with sudo)

• test - the name of the new user

Set the password for the new user.

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.

If you want, you can put it in your .bashrc so that rvm is available any time you login as the user.

You can verify that the rvm script is being used by checking the head of type. It should be a function and not hashed.

Next, install Ruby 2.0.0. RVM will ask for the user’s password because it needs to install an assortment of dependencies before it can make Ruby. Since RVM builds Ruby from source, 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

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 ’/’ for the path.

My results converged around 300 requests/second. WEBrick is not known for its speed. Go ahead and interrupt the server with Ctrl-c.

Install Thin

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 Ab Benchmark Test

Now, try the load test again. It should be a bit faster this time.

Ab Apache Benchmark Example Post

At least in this case, it looks like Thin makes for a notably faster server than WEBrick at over 700 requests/second (You can try raising the total requests, but it didn’t get much higher for me).

Note: I was able to get 1000 requests/second on an Arch Linux droplet.

Apache Ab Benchmarking

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:

Ab Apache Benchmark Https

<div class=“author”>Submitted by: <a href=“http://robertqualls.com”>Robert Qualls</a></div>