1.安装相关工具
yum install -y httpd httpd-tools gnuplot
2. 使用ab进行测试:
$ab -c 10 -n 50 -k -g /data/www/bench1.tsv http://www.zrwm.com/
$ab -c 10 -n 50 -k -g /data/www/bench2.tsv http://www.zrwm.com/
$ab -c 10 -n 50 -k -g /data/www/bench3.tsv http://www.zrwm.com/
ab命令参数说明:
-c: number of concurrent users/seconds
-n: number of requests/user/seconds
-k: Keepalived supported
生成的TSV文件,头部的几个列说明:
ctime: Connection Time
dtime: Processing Time
ttime: Total Time
wait: Waiting Time
3.基于这些tsv文件,使用gnuplot生成png格式图表
$ cd /data/www
$ gnuplot
gnuplot> set terminal png
Terminal type set to 'png'
gnuplot> set output "benchmark.png"
gnuplot> set title "Benchmark for www.zrwm.com"
gnuplot> set size 1,1
gnuplot> set grid y
gnuplot> set xlabel 'Request'
gnuplot> set ylabel 'Response Time (ms)'
gnuplot> plot "bench1.tsv" using 10 smooth sbezier with lines title "Benchmark 1:", "bench2.tsv" using 10 smooth sbezier with lines title "Benchmark 2:", "bench3.tsv" using 10 smooth sbezier with lines title "Benchmark 3:"
gnuplot> exit
我们可以将第3步的gnuplot代码部分做成模板benchmark.tpl,以简化生成图表的过程:
# output as png image
set terminal png
# save file to "benchmark.png"
set output "benchmark.png"
# graph title
set title "Benchmark for blog.secaserver.com"
# aspect ratio for image size
set size 1,1
# enable grid on y-axis
set grid y
# x-axis label
set xlabel "Request"
# y-axis label
set ylabel "Response Time (ms)"
# plot data from bench1.tsv,bench2.tsv and bench3.tsv using column 10 with smooth sbezier lines
plot "bench1.tsv" using 10 smooth sbezier with lines title "Benchmark 1:", \
"bench2.tsv" using 10 smooth sbezier with lines title "Benchmark 2:", \
"bench3.tsv" using 10 smooth sbezier with lines title "Benchmark 3:"
下次在ab测试后,运行:
$gnuplot benchmark.tpl
1. httperf安装
wget ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.9.0.tar.gz
tar zxvf httperf-0.9.0.tar.gz
cd httperf-0.9.0
./configure –prefix=/usr/local/httperf
make && make install
httpref是通过命令行来调用。它有如下参数
httperf –help
Usage: httperf [-hdvV] [--add-header S] [--burst-length N] [--client N/N]
[--close-with-reset] [--debug N] [--failure-status N]
[--help] [--hog] [--http-version S] [--max-connections N]
[--max-piped-calls N] [--method S] [--no-host-hdr]
[--num-calls N] [--num-conns N] [--period [d|u|e]T1[,T2]]
[--port N] [--print-reply [header|body]] [--print-request [header|body]]
[--rate X] [--recv-buffer N] [--retry-on-failure] [--send-buffer N]
[--server S] [--server-name S] [--session-cookies]
[--ssl] [--ssl-ciphers L] [--ssl-no-reuse]
[--think-timeout X] [--timeout X] [--uri S] [--verbose] [--version]
[--wlog y|n,file] [--wsess N,N,X] [--wsesslog N,X,file]
[--wset N,X]
其中常用的参数的含义
–server S web服务器地址
–num-conns N 测试联接数
–num-calls N 每连接中发起联接数，一般是1
–rate N 每秒请求数
–port N 测试端口
−−method S 测试HTTP方法，默认为GET
–uri S 测试网页，默认为/
–timeout N 等待服务器响应时间
使用实例：
httperf –server www.zrwm.com –port 80 –num-conns 200 –timeout 5 –uri /10k
每次设置参数来测试有点麻烦,使用autobench结合httperf来测试就会方便很多。autobench是perl脚本写的自动测试工具,它调用httperf来测试.
2.autobench安装
wget http://www.xenoclast.org/autobench/downloads/autobench-2.1.2.tar.gz
tar zxvf autobench-2.1.2.tar.gz
cd autobench-2.1.2
单机使用实例：
autobench –single_host –host1 www.zrwm.com –uri1 /10k –port1 80 –quiet –low_rate 20 –high_rate 200 –rate_step 20 –num_call 1 –num_conn 500 –timeout 5 –file results.tsv
双机实例:
autobench –host1=v1.zrwm.com –port1=8001 –host2=v2.zrwm.com –port2=80 –uri1=/ –uri2=/a.php –quiet –low_rate=500 –high_rate=5000 –rate_step=100 –num_call=1 –num_conn=10000 –timeout=10 –file result.tsv
参数含义
–single_host 只测单机
–host1 测试主机地址
–uri1 host1 测试URI
–quiet 安静模式
–low_rate 测试时最低请求数(指 httperf)
–hight_rate 测试时最高请求数
–rate_step 每次测试请求数增加步长
–num-call 同httperf
–num_conn 同httperf
–file 测试结果输出的 tsv文件
3.gnuplot安装(安装之前,请先安装好gd库)
wget http://nchc.dl.sourceforge.net/sourceforge/gnuplot/gnuplot-4.6.0.tar.gz
tar zxvf gnuplot-4.6.0.tar.gz
cd gnuplot-4.6.0
./configure –prefix=/usr/local/gnuplot –with-gd=/usr/local/gd2/
make && make install
注：如果make的时候出现undefined reference to `libiconv’的类似错误,
可以直接执行：export LIBS=”-liconv”
然后再次configure后,重新进行编译安装make && make install
vi /etc/profile
#将/usr/local/gnuplot/bin:/usr/local/httperf/bin 添加到PATH中
export PATH=/usr/local/bin:/usr/local/gnuplot/bin:/usr/local/httperf/bin:$PATH
source /etc/profile
修改 bench2graph
cp /usr/local/bin/bench2graph /usr/local/bin/bench2png
vi /usr/local/bin/bench2png
将72行的echo set terminal postscript color > gnuplot.cmd
修改为echo set terminal png large size 640,480 truecolor > gnuplot.cmd
将77行的 set data style
修改为 set style data
生成PNG图像：
bench2png results.tsv results.png
参考：
http://www.xenoclast.org/autobench/
http://www.gnuplot.info/
As a website owner your website performance is crucial to your business. You would expect your website to be able to cope with thousands of visits per minute but unless you’ve prepared for it by purchasing quality hosting services and tuning the servers there is a good change that your website won’t cope with a lot of traffic and in a lot of cases can lead to a loss of revenue. Tuning your web servers to handle more traffic without crashing is a science of its own and there are many ways to improve performance but before you dive in and start tweaking your Apache or MySQL configurations you need some way of measuring the website performance improvements you make. There are many tools available for speed testing your website and they all have their merits. One tool that is easy to use is Siege (Website).
Siege is a command line program that helps measure the speed of your website and provides a summary of the performance which you can use to measure the changes on your web servers.
Installing Siege on Ubuntu (and derivatives)
Siege is part of the standard ubuntu packages, so you should install it in the standard way:
sudo apt-get install siege
Additionally, you can download, compile and install the latest version of Siege. Use the steps below.
Installing Siege on Mac OSX
As far as I am aware there isn’t a package version of Siege for OSX so you can either download,compile and install Siege manually or use Homebrew to install.
Manually compile and install
Do the following to download, compile and install Siege on your OSX.
$ curl http://www.joedog.org/pub/siege/siege-latest.tar.gz -o siege-latest.tar.gz
$ tar xvfz siege-latest.tar.gz
$ cd siege-2.72
$ ./configure
$ make
$ make install
This will install Seige to /usr/local/bin/siege.
Installation via Homebrew
First, install homebrew using the instructions fromhttps://github.com/mxcl/homebrew/wiki/installation. Once installed you can simply install Siege in one command:
Using Siege
Now that Siege is installed we can begin speed testing your website. First thing to do is to create the siege config file in your home directory.
~ $ siege.config
New configuration template added to /home/andrew/.siegerc
Run siege -C to view the current settings in that file
We’ll run our first test shortly but first a word of warning!. Siege is a powerful tool and can quite easily bring your web servers down if used incorrectly! I recommend you test this on your own websites and not those of a third party.
OK, lets run our first test. We’ll test the homepage of our site by simulating 10 users with a delay of up to 10 seconds between requests.
~ $ siege -c10 -d10 -r1 -v http://www.mywebsite.com/
** SIEGE 2.72
** Preparing 10 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200 0.12 secs: 4123 bytes ==> /
HTTP/1.1 200 0.11 secs: 4123 bytes ==> /
HTTP/1.1 200 0.11 secs: 4123 bytes ==> /
HTTP/1.1 200 0.12 secs: 4123 bytes ==> /
HTTP/1.1 200 0.11 secs: 4123 bytes ==> /
HTTP/1.1 200 0.13 secs: 4123 bytes ==> /
HTTP/1.1 200 0.11 secs: 4123 bytes ==> /
HTTP/1.1 200 0.11 secs: 4123 bytes ==> /
HTTP/1.1 200 0.12 secs: 4123 bytes ==> /
HTTP/1.1 200 0.11 secs: 4123 bytes ==> /
done.
Transactions: 10 hits
Availability: 100.00 %
Elapsed time: 8.12 secs
Data transferred: 0.04 MB
Response time: 0.11 secs
Transaction rate: 1.23 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 0.14
Successful transactions: 10
Failed transactions: 0
Longest transaction: 0.13
Shortest transaction: 0.11
Let’s break this down a little. First we entered the siege command with a number of parameters:
- -c10 is the number of concurrent users we want to simulate.
- -r1 is the number of repetitions, in this case, 1.
- -d10 is the delay between each user request (each siege simulated users sleeps for a random interval in seconds between 0 and 10).
- -v is to show the output of each request.
- Finally the url to test. My tests were run on a bona fide website but I have changed the domain name in my examples.
Once you hit enter Siege will run and output it’s results. The first set of results shows each request. This shows the HTTP method, the returned HTTP result code (200 is good ), the time taken in seconds, the number of bytes retreived and finally the URL requested. You can edit your ~/.siegerc to show the full URL if you need to.
After the requests have completed Siege will show you a summary report. This report is documented in the siege man page, which I have reproduced below:
Transactions
The number of server hits. In the example, 25 simulated users [ -c25 ] each hit the server 10 times [ -r10 ], a total of 250 transactions. It is possible for the number of transactions to exceed the number of hits that were scheduled. Siege counts every server hit a transaction, which means redirections and authentication challenges count as two hits, not one. With this regard, siege follows the HTTP specification and it mimics browser behavior.
Availability
This is the percentage of socket connections successfully handled by the server. It is the result of socket failures (including timeouts) divided by the sum of all connection attempts. This number does not include 400 and 500 level server errors which are recorded in “Failed transactions” described below.
Elapsed time
The duration of the entire siege test. This is measured from the time the user invokes siege until the last simulated user completes its transactions. Shown above, the test took 14.67 seconds to complete.
Data transferred
The sum of data transferred to every siege simulated user. It includes the header information as well as content. Because it includes header information, the number reported by siege will be larger then the number reported by the server. In internet mode, which hits random URLs in a configuration file, this number is expected to vary from run to run.
Response time
The average time it took to respond to each simulated user’s requests.
Transaction rate
The average number of transactions the server was able to handle per second, in a nutshell: transactions divided by elapsed time.
Throughput
The average number of bytes transferred every second from the server to all the simulated users.
Concurrency
The average number of simultaneous connections, a number which rises as server performance decreases.
Successful transactions
The number of times the server responded with a return code < 400.
Failed transactions
The number of times the server responded with a return code >= 400 plus the sum of all failed socket transactions which includes socket timeouts.
Longest transaction
The greatest amount of time that any single transaction took, out of all transactions.
Shortest transaction
The smallest amount of time that any single transaction took, out of all transactions.
Speed testing more than one url
If you need to test more than one URL then you will need to tell Siege to use a file to load the URL’s from. Simply create a text file called urls.txt and add each URL you want to test on a separate line.
$ vim urls.txt
http://www.mywebsite.com/about-us/
http://www.mywebsite.com/contact-us/
To tell Siege to use your urls.txt you need to use the -f parameter.
siege -v -c10 --reps=once -d5 -f urls.txt
** SIEGE 2.72
** Preparing 10 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200 0.61 secs: 7817 bytes ==> /about-us/
HTTP/1.1 200 0.66 secs: 7821 bytes ==> /about-us/
HTTP/1.1 200 0.67 secs: 7821 bytes ==> /about-us/
HTTP/1.1 200 0.67 secs: 7821 bytes ==> /about-us/
HTTP/1.1 200 0.72 secs: 7818 bytes ==> /about-us/
HTTP/1.1 200 0.74 secs: 7821 bytes ==> /about-us/
HTTP/1.1 200 0.78 secs: 7821 bytes ==> /about-us/
HTTP/1.1 200 0.60 secs: 8050 bytes ==> /contact-us/
HTTP/1.1 200 0.60 secs: 8050 bytes ==> /contact-us/
HTTP/1.1 200 0.63 secs: 7821 bytes ==> /about-us/
HTTP/1.1 200 0.68 secs: 7819 bytes ==> /about-us/
HTTP/1.1 200 0.69 secs: 7821 bytes ==> /about-us/
HTTP/1.1 200 0.61 secs: 8052 bytes ==> /contact-us/
HTTP/1.1 200 0.60 secs: 8046 bytes ==> /contact-us/
HTTP/1.1 200 0.61 secs: 8043 bytes ==> /contact-us/
HTTP/1.1 200 0.62 secs: 8051 bytes ==> /contact-us/
HTTP/1.1 200 0.60 secs: 8044 bytes ==> /contact-us/
HTTP/1.1 200 0.61 secs: 8052 bytes ==> /contact-us/
HTTP/1.1 200 0.65 secs: 8051 bytes ==> /contact-us/
HTTP/1.1 200 0.62 secs: 8051 bytes ==> /contact-us/
done.
Transactions: 20 hits
Availability: 100.00 %
Elapsed time: 9.32 secs
Data transferred: 0.15 MB
Response time: 0.65 secs
Transaction rate: 2.15 trans/sec
Throughput: 0.02 MB/sec
Concurrency: 1.39
Successful transactions: 20
Failed transactions: 0
Longest transaction: 0.78
Shortest transaction: 0.60
As you can see, Siege has requested both URL’s from the file at random intervals.
Speed testing a web page with all it’s assets (JavaScript,CSS, Images etc)
Everything we have done so far has been testing single html files which is useful for testing page generation. But what if we need to find out the speed of a whole web page including all the images, javascript, css files, video etc? Simple, you put all the URL’s of all the webpage assets into the urls.txt file. However, doing this by hand can be quite painful. Fortunately we can use a proxy tool to create the URL’s for us.
Introducing sproxy
The author of Siege, Jeffrey Fulmer (see the siege websute) has also written a companion program to Siege called ‘sproxy’. Quite simple, sproxy logs all urls to a text file for use with Siege. To do this you need to tell your web browser to connect to the proxy and then simply load your webpage.
Installing sproxy on Ubuntu (and derivatives)
Unlike Siege, sproxy doesn’t appear to be packaged for Ubuntu, so we need to compile and install it.
$ curl http://www.joedog.org/pub/sproxy/sproxy-latest.tar.gz -o sproxy-latest.tar.gz
$ tar xvfz sproxy-latest.tar.gz
$ cd sproxy-1.02/
$ ./configure
$ make
$ sudo make install
Once sproxy is installed you should configure your browser to use the proxy. In Firefox, go to Preferences > Advanced > Network and click the ‘settings’ button. Then select ‘Manual Proxy Configuration’ and enter ’127.0.0.1′ in the ‘HTTP Proxy:’ field, and ’9001′ in the Port Field. Once you have done this, click ‘OK’ and close your Preferences dialog.
[screenie]
Go to your terminal and launch sproxy. By default it will bind to the localhost and use port 9001. Now go to your browser and load a single page on your website. When it has finished loading, go back to your terminal and quit sproxy using CTRL-C.
andrew@andrew-laptop ~ $ sproxy
SPROXY v1.02 listening on port 9001
...appending HTTP requests to: /home/andrew/urls.txt
...default connection timeout: 120 seconds
^C
andrew@andrew-laptop ~ $
Now view your urls.txt file and you should see the URL’s of all images,css and javascript (and any other assets) that your web page contains. Check the file through and remove any URL’s you don’t want to test such as Google Analytics.
Once you’ve cleaned your urls.txt file you can then siege it as we did previously. This time we’ll simulate one user making one request of the whole web page, assets and all.
siege -c1 --reps=once -f urls.txt
** SIEGE 2.72
** Preparing 1 concurrent users for battle.
The server is now under siege.. done.
Transactions: 38 hits
Availability: 100.00 %
Elapsed time: 26.23 secs
Data transferred: 0.38 MB
Response time: 0.19 secs
Transaction rate: 1.45 trans/sec
Throughput: 0.01 MB/sec
Concurrency: 0.27
Successful transactions: 38
Failed transactions: 0
Longest transaction: 0.62
Shortest transaction: 0.10
Simulate Browser Caching
Siege, by default, requests each URL from the server regardless of any expiry headers sent by the server. This allows us to simulate a page load with an empty cache but we can also configure Siege to request the URLs and respect any expires headers that are sent. To do this, open your ~/.siegerc file in your text editor and find the Cache revalidation section (around line 101 in my file). Simply change the line to ‘cache = true’, save it and re-run your test, this time with the -v flag.
