Databases, Systems & Networks

A few articles ago, I wrote about using the “apachebench” or “ab” utility to benchmark your website (see: apachebench). Ab is a great tool, but since then, I have found and fallen in love with a new tool for benchmarking your website. This new tool is named “siege”.

Install Siege on CentOS 6

CentOS 6 has added the siege package to the CentOS EPEL (Extra Packages for Enterprise Linux) repository which makes installation easy using yum if you have the EPEL repository installed. If you need to install it still, you can do it using these quick steps:

# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# rpm -Uvh ./epel-release-6-8.noarch.rpm
Preparing...                ########################################### [100%]
package epel-release-6-8.noarch is already installed

Once the EPEL repository is installed, you can go ahead and install the siege package:

# yum install siege

Using Siege to Benchmark Your Website

We can get really detailed usage information on the siege utility in the man pages. We can get a list of the switches that siege can use by using the –help option:

# siege --help
SIEGE 3.0.0
Usage: siege [options]
       siege [options] URL
       siege -g URL
Options:
  -V, --version             VERSION, prints the version number.
  -h, --help                HELP, prints this section.
  -C, --config              CONFIGURATION, show the current config.
  -v, --verbose             VERBOSE, prints notification to screen.
  -q, --quiet               QUIET turns verbose off and suppresses output.
  -g, --get                 GET, pull down HTTP headers and display the
                            transaction. Great for application debugging.
  -c, --concurrent=NUM      CONCURRENT users, default is 10
  -i, --internet            INTERNET user simulation, hits URLs randomly.
  -b, --benchmark           BENCHMARK: no delays between requests.
  -t, --time=NUMm           TIMED testing where "m" is modifier S, M, or H
                            ex: --time=1H, one hour test.
  -r, --reps=NUM            REPS, number of times to run the test.
  -f, --file=FILE           FILE, select a specific URLS FILE.
  -R, --rc=FILE             RC, specify an siegerc file
  -l, --log[=FILE]          LOG to FILE. If FILE is not specified, the
                            default is used: PREFIX/var/siege.log
  -m, --mark="text"         MARK, mark the log file with a string.
  -d, --delay=NUM           Time DELAY, random delay before each requst
                            between 1 and NUM. (NOT COUNTED IN STATS)
  -H, --header="text"       Add a header to request (can be many)
  -A, --user-agent="text"   Sets User-Agent in request
  -T, --content-type="text" Sets Content-Type in request

Copyright (C) 2013 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.

so, with these options in mind, allow me to demonstrate a few of the coolest siege options that I like best:

Lire la suite…

source: nixCraft

You can benchmark Apache, IIS and other web server with apache benchmarking tool called ab. Recently I was asked to performance benchmarks for different web servers.

Apache benchmark

It is true that benchmarking a web server is not an easy task. From how to benchmark a web server:

First, benchmarking a web server is not an easy thing. To benchmark a web server the time it will take to give a page is not important: you don’t care if a user can have his page in 0.1 ms or in 0.05 ms as nobody can have such delays on the Internet.

What is important is the average time it will take when you have a maximum number of users on your site simultaneously. Another important thing is how much more time it will take when there are 2 times more users: a server that take 2 times more for 2 times more users is better than another that take 4 times more for the same amount of users. »

Here are few tips to carry out procedure along with an example:

Apache Benchmark Procedures

• You need to use same hardware configuration and kernel (OS) for all tests
• You need to use same network configuration. For example, use 100Mbps port for all tests
• First record server load using top or uptime command
• Take at least 3-5 readings and use the best result
• After each test reboot the server and carry out test on next configuration (web server)
• Again record server load using top or uptime command
• Carry on test using static html/php files and dynamic pages
• It also important to carry out test using the Non-KeepAlive and KeepAlive (the Keep-Alive extension to provide long-lived HTTP sessions, which allow multiple requests to be sent over the same TCP connection) features
• Also don’t forget to carry out test using fast-cgi and/or perl tests

Lire la suite…