官术网_书友最值得收藏!

Understanding Siege

Siege is a load testing and benchmarking tool that allows us to further analyze our web server's performance. Let's begin by installing Siege inside our Docker container.

From the container's command line, please download and decompress version 4.0.2 of Siege:

# wget -O siege-4.0.2.tar.gz http://download.joedog.org/siege/siege-4.0.2.tar.gz 
# tar -xzvf siege-4.0.2.tar.gz 

Then, please enter Siege's source code directory to compile and install the software:

# cd siege-4.0.2 
# ./configure 
# make 
# make install 

For these tests with Siege, we will be using the -b, -c, and -r switches. Here are the definitions of these switches:

  • -b, enables benchmark mode, which means that there are no delays between iterations
  • -c, enables concurrency in order to perform multiple requests at the same time
  • -r, determines the number of requests to perform with each concurrent user

Of course, you can get more information on Siege's command-line options by invoking the manual from the container's command line:

# man siege  

Now launch a Siege benchmark test:

# siege -b -c 3000 -r 100 localhost/index.html 

You will then get a benchmark test report like this one:

The Siege benchmark report confirms the results that were obtained from AB

As you can see, the results match those that we got from AB previously. Our test shows a transaction rate of almost 800 transactions per second.

Siege also comes with a handy tool named Bombard that can automate tests and help to verify scalability. Bombard allows you to use Siege with an ever-increasing number of concurrent users. It can take a few optional arguments. These are: the name of a file containing URLs to use when performing the tests, the number of initial concurrent clients, the number of concurrent clients to add each time Siege is called, the number of times Bombard should call Siege and the time delay, in seconds, between each request.

We can, therefore, try to confirm the results of our previous tests by issuing the following commands inside the container:

# cd /srv/www
# touch urlfile.txt # for i in {1..4}; do echo "http://localhost/index.html" >> urlfile.txt ; done # bombardment urlfile.txt 10 100 4 0

Once done, you should obtain a report similar to the following one:

The results show that the longest transaction is much higher when there are 210 or more concurrent users

Try again, but by requesting the PHP file:

# echo "http://localhost/index.php" > urlfile.txt 
# for i in {1..3}; do echo "http://localhost/index.php" >> urlfile.txt ;  done 
# bombardment urlfile.txt 10 100 4 0 

This test should provide results similar to these:

The efficiency of serving dynamic content is analogous to that of serving static content, but with a much lower transaction rate

The second Terminal window that is running top is now showing 50% usage of both of the available processors and almost 50% RAM usage on my computer:

The container’s usage of CPU and memory resources when it is submitted to benchmarking tests

We now know that, when there are not many concurrent requests, this hardware can allow for good performance on a small scale, with 800 transactions per second on static files and about 200 transactions per second on pages that have dynamically generated content.

Now that we have a better idea of the base speed performance of our web server based solely on our hardware's resources, we can now start to truly measure the speed and efficiency of the web server's dynamically generated content through profiling. We will now proceed to install and configure tools that will allow us to profile and optimize PHP code.

主站蜘蛛池模板: 黄平县| 长垣县| 宿州市| 盐边县| 郴州市| 长岛县| 高尔夫| 青神县| 东源县| 南康市| 灵石县| 内丘县| 南川市| 洞头县| 凤山市| 衡阳市| 扎鲁特旗| 平昌县| 沁源县| 广德县| 嘉黎县| 临城县| 阿拉善左旗| 阿坝| 巴彦淖尔市| 凯里市| 塔城市| 博野县| 陈巴尔虎旗| 巴林左旗| 绥化市| 寻乌县| 天水市| 维西| 孙吴县| 股票| 永昌县| 康乐县| 沐川县| 信阳市| 阳谷县|