You are here

Drupal server performance (under siege)

Drupal server performance can be tricky especially with high traffic sites. If you are upgrading from an existing platform or migrating to a new server you can use the Apache access logs to generate close to real workloads, using Seige, on the new server and make adjustments before going live.

Note: The script have now been updated to use PHP 5.4 and SQLite3 (13/05/14).

Analyzing Apache access logs

Siege uses a file with URLs that it should "hit" and to generate this file based on Apache access logs you can use this PHP script that I have created. It's some what CPU and IO hungry, so if you are using it give it some time to execute. I have used it on several GB of Apache logs and used to test several sites. The script uses a local SQLite database to store analyzed log files, so URLs can be generated form different conditions to optimize your load tests.

You can download the script from GitHub here: Access2Siege

To analyze an Apache access file the following command can be used, but be aware that this match the logging format I had for my Apache. So you may need to change the pattern (-p) and time format (-t) parameters. See the documentation in the top of the script for more information about its usage.

~$ ./access2siege.php -i access.log -p "0,3,6,8" -t "d/m/y:H:i:s"

After you have loaded all your access information into the SQLite database, the script can provide statistical information about the content in the database. For more information about the possibilities see the documentation inside the script.

~$ ./access2siege.php -c urls
~$ ./access2siege.php -c urls -x '/user
~$ ./access2siege.php -c ips

The first shows the number of URLs in the database. The next shows the number of URLs that starts with "/user" and the last counts the number of IPs in the database. You can use this information to make decisions about output generating later.

Large access logs

It takes time to analyze large access logs, so you may want to split the logs into smaller parts and only analyze some of theme. The following commands splits a log file into 25 Mb pieces and analyzes the ones containing the names in the parentheses.

~$ split -b 25m access.log.3 access_3_logs_
~$ for fh in access_3_logs_*(a|b|c|h|j|k|t|q|w|g|p|r); do ./access2siege.php -i $(fh) -p "1,4,7,9" -t "d/m/y:H:i:s"; done

Outputting URLs

The following command will generate Siege URL files each containing 1.000.000 URLs, which can be used to "hit" the server

~$ ./access2siege.php -o <site>_{n}.txt -d http://stg.<site> -l 1000000


It's time to install Siege either from your package system or from source code, as shown below.

~$ wget
~$ tar -zxvf siege-latest.tar.gz
~$ cd siege-2.70
~$ ./configure --prefix=/opt/siege-2.70
~$ make
~$ sudo make install
~$ sudo ln -s /opt/siege-2.70/bin/* /usr/local/bin/

Installation on Mac

If you are you are using a Mac, you can use home brew to install Siege, as shown below.

~$ brew install siege

Running Siege

If you simply want to test that Siege is correctly installed or just run a simple load test against a single URL use this command. It will execute 10 concurrently threads and stop after 4 minutes in verbose mode, so you can see what its during.

~$ siege -c 10 -t 4M -v http://linuxdev.localhost

The result of the test above could look like this, where you should look at the transaction rate and throughout. Do not forget to look at failed transactions, as they may occur if the server stops responding when the load gets to high.

Test Result
Transactions 3813 hits
Availability 100.00 %
Elapsed time 239.03 secs
Data transferred 19.96 MB
Response time 0.10 secs
Transaction rate 15.95 trans/sec
Throughput 0.08 MB/sec
Concurrency 1.60
Successful transactions 3813
Failed transactions 0
Longest transaction 1.22
Shortest transaction 0.08

To run Siege with a URL file simply add the -f and the file you want to use and it will "hit" those URLs.

~$ siege -c 100 -d 3 -t 60m --log=siege.log -f access-urls-1.log

Logged in

It's possible to run Siege as a logged in user by using a configuration file with the following content (remember to modify the credentials).

logfile = siege.log
verbose = false
fullurl = true
show-logfile = true
logging = true
logfile = siege.log
protocol = HTTP/1.1
chunked = true
cache = false
connection = close
concurrent = 25
time = 60M
file = access-urls-1.log
delay = 3
timeout = 30
internet = false
user-agent = Siege benchmark test
accept-encoding = gzip
spinner = true
login-url = https://<site>/user POST name=admin&pass=12345&form_id=user_login&op=Log+in

Running Siege with the configuration file.

~$ siege -R siege_login_rc

Get Apache style log from Varnish

You can get logging information from Varnish in the same format as Apache uses by running this command on your Varnish server. Use ctrl+c to stop logging to the file.

~$ varnishncsa -w varnish.log

Adjustments parameters

This is a list of things that may improve performance, but be aware that it may also have the opposite effect and decrease performance. Remember to run Siege before adjusting any of you configuration parameters, so you have a reference point for your performance improvements. You should also run Siege under the same conditions and with the same parameters every time to make the results comparable.

  • MySQL innodb (buffers)
  • Apache threads
  • MySQL engine
  • Disk performance
  • APC configuration
  • PHP configuration
  • Reverse caching (Varnish)

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.