Apache 压力测试
[ 2009/08/23 12:45 | by selboo ]
压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。
1.apache安装
下载：
从Apache官方网站http://httpd.apache.org/download.cgi下载httpd-2.0.58.tar.gz。
安装：
先解压缩tar文件
tar -zxvf httpd-2.0.58.tar.gz
(1)./configure -prefix=/usr/local/apache2test -enable-so -enable-shared=max -with-mpm=worker -enable-deflate -enable-headers -enable-rewrite -enable-proxy -enable-proxy -enable-ssl -with-ssl=/path/to/install/openssl_0.97i -enable-modules=all && make && make install
(这是正式服务器上的apache2的编译参数，其中–with-mpm=worker –with-ssl=/path/to/install/openssl_0.97i可以根据实际情况做出修改)
然后安装php，并且在/usr/local/apache2test/conf目录下的httpd.conf里面的DSO支持之后加入
AddType application/x-httpd-php .php .phtml .html .htm
AddType application/x-httpd-php-source .phps
最后将测试的php网页文件添加到/usr/local/apache2test/htdocs目录下
(2) make
(3)make install
2.测试工具说明以及安装
ab:
ab是Apache超文本传输协议(HTTP)的性能测试工具。 其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求；
概要:运行/usr/local/apache-install-path/bin/ab -help查看ab的具体命令选项；
命令选项-c concurrency 一次产生的请求个数。默认是一次一个。
-n requests 在测试会话中所执行的请求个数。 默认时，仅执行一个请求，但通常其结果不 具有代表意义
运行结果:主要要注意的是以下内容
Time taken for tests: 总共执行所花费的时间.(以上 1000 次共多久)
Requests per second: 每秒平均可以处理多少个connection.
备注:每次仅仅能针对一个连接做重复的测试。
Siege:
是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。
下载/安装
Siege时一个开放源代码项目，可以在http://www.google.com上查找
备注：最好选择2.5以上版本，因为高版本多包括一个辅助工具，能够做增量压力测试，低版本不包括此工具。
安装：
./configure -prefix=/path/to/install && make && make install
使用说明:
siege使用
在/path/to/install/bin/目录下创建需要测试的链接文件，如www.test.com.url,添加需要的测试的链接
http://10.5.3.122/test/google.php/
http://10.5.3.122/test/baidu.php/
http://10.5.3.122/test/sogou.php/
然后保存。
siege使用样例：
siege -c 20 -r 2 -f www.chedong.com.url
参数说明：
-c 20 并发20个用户
-r 2 重复循环2次
-f www.test.com.url 任务列表：URL列表
输出样例：
** Siege 2.59
** Preparing 20 concurrent users for battle. 这次“战斗”准备了20个并发用户
The server is now under siege.. done. 服务在“围攻”测试中：
Transactions: 40 hits 完成40次处理
Availability: 100.00 % 成功率
Elapsed time: 7.67 secs 总共用时
Data transferred: 877340 bytes 共数据传输：877340字节
Response time: 1.65 secs 相应用时1.65秒：显示网络连接的速度
Transaction rate: 5.22 trans/sec 平均每秒完成5.22次处理：表示服务器后台处理的速度
Throughput: 114385.92 bytes/sec 平均每秒传送数据：114385.92字节
Concurrency: 8.59 最高并发数 8.59
Successful transactions: 40 成功处理次数
Failed transactions: 0 失败处理次数
bombardment使用样例:
bombardment www.test.com.url 5 3 4 1
初始化URL列表：www.test.com.url
初始化为：5个用户
每次增加：3个用户
运行：4次
每个客户端之间的延迟为：1秒
输出样例和siege一致，但是会在每一次增量结束之后都有输出。
3.测试方法说明
测试步骤：
方法1.安装apache2后，直接使用apache2的默认设置配置，不做任何修改，进行测试；
方法2.按照以前文档提出的Web容量规划和内存的大小，计算出相应的启动进程数，配置httpd.conf文件，再进行测试；
ServerLimit 400
StartServers 20
MinSpareServers 20
MaxSpareServers 50
MaxClients 300
MaxRequestsPerChild 10000
方法3.超过极限设置，进行测试。(规划容量的2倍进行)
1000个链接，分为不同的并发数请求，10、50、100、200、300、500
ab测试:
/usr/local/apache2.53/bin/ab -n 1000 -c 10 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 50 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 100 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 200 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 300 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 500 http://10.5.3.122/test/google.php/
siege测试:
/usr/local/siege/bin/siege -c 10 -r 100 -f www.test.com.url
/usr/local/siege/bin/siege -c 50 -r 20 -f www.test.com.url
/usr/local/siege/bin/siege -c 100 -r 10 -f www.test.com.url
/usr/local/siege/bin/siege -c 200 -r 5 -f www.test.com.url
/usr/local/siege/bin/siege -c 300 -r 3 -f www.test.com.url
/usr/local/siege/bin/siege -c 500 -r 2 -f www.test.com.url
增量测试:
/usr/local/siege/bin/bombardment www.test.com.url 1 100 5 1
/usr/local/siege/bin/bombardment www.test.com.url 1 100 6 1
4.测试结果总结
ab测试:测试并发连接数在50~500的情况下，方法2比方法1性能略有提升，但是相差在10个并发连接数左右，并且方法1方法2在测试并发数100的情况下，实际并发数都相差无几。
siege测试:测试并发数从50之后直到500，性能都有提升，并且在测试并发数100、200、500的情况下，提升相差10~30个实际并发数。
bombardment测试:相差不大。本次测试的结果不太理想，性能的变化不显著，也不明显，可以所属于失败的测试结果。
分析原因：
1.本身硬件配置不高，所以默认设置和修改后的设置变化不明显，对性能的提升也明显不足；
2.负载情况太少，由于系统性能原因，增量测试都不能过大的进行，系统性能load average过高；
3.测试页面程序也太少，没有太大说服力。
网站性能测试报告模板
下载文件 (已下载 255 次)
1.apache安装
下载：
从Apache官方网站http://httpd.apache.org/download.cgi下载httpd-2.0.58.tar.gz。
安装：
先解压缩tar文件
tar -zxvf httpd-2.0.58.tar.gz
(1)./configure -prefix=/usr/local/apache2test -enable-so -enable-shared=max -with-mpm=worker -enable-deflate -enable-headers -enable-rewrite -enable-proxy -enable-proxy -enable-ssl -with-ssl=/path/to/install/openssl_0.97i -enable-modules=all && make && make install
(这是正式服务器上的apache2的编译参数，其中–with-mpm=worker –with-ssl=/path/to/install/openssl_0.97i可以根据实际情况做出修改)
然后安装php，并且在/usr/local/apache2test/conf目录下的httpd.conf里面的DSO支持之后加入
AddType application/x-httpd-php .php .phtml .html .htm
AddType application/x-httpd-php-source .phps
最后将测试的php网页文件添加到/usr/local/apache2test/htdocs目录下
(2) make
(3)make install
2.测试工具说明以及安装
ab:
ab是Apache超文本传输协议(HTTP)的性能测试工具。 其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求；
概要:运行/usr/local/apache-install-path/bin/ab -help查看ab的具体命令选项；
命令选项-c concurrency 一次产生的请求个数。默认是一次一个。
-n requests 在测试会话中所执行的请求个数。 默认时，仅执行一个请求，但通常其结果不 具有代表意义
运行结果:主要要注意的是以下内容
Time taken for tests: 总共执行所花费的时间.(以上 1000 次共多久)
Requests per second: 每秒平均可以处理多少个connection.
备注:每次仅仅能针对一个连接做重复的测试。
Siege:
是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。
下载/安装
Siege时一个开放源代码项目，可以在http://www.google.com上查找
备注：最好选择2.5以上版本，因为高版本多包括一个辅助工具，能够做增量压力测试，低版本不包括此工具。
安装：
./configure -prefix=/path/to/install && make && make install
使用说明:
siege使用
在/path/to/install/bin/目录下创建需要测试的链接文件，如www.test.com.url,添加需要的测试的链接
http://10.5.3.122/test/google.php/
http://10.5.3.122/test/baidu.php/
http://10.5.3.122/test/sogou.php/
然后保存。
siege使用样例：
siege -c 20 -r 2 -f www.chedong.com.url
参数说明：
-c 20 并发20个用户
-r 2 重复循环2次
-f www.test.com.url 任务列表：URL列表
输出样例：
** Siege 2.59
** Preparing 20 concurrent users for battle. 这次“战斗”准备了20个并发用户
The server is now under siege.. done. 服务在“围攻”测试中：
Transactions: 40 hits 完成40次处理
Availability: 100.00 % 成功率
Elapsed time: 7.67 secs 总共用时
Data transferred: 877340 bytes 共数据传输：877340字节
Response time: 1.65 secs 相应用时1.65秒：显示网络连接的速度
Transaction rate: 5.22 trans/sec 平均每秒完成5.22次处理：表示服务器后台处理的速度
Throughput: 114385.92 bytes/sec 平均每秒传送数据：114385.92字节
Concurrency: 8.59 最高并发数 8.59
Successful transactions: 40 成功处理次数
Failed transactions: 0 失败处理次数
bombardment使用样例:
bombardment www.test.com.url 5 3 4 1
初始化URL列表：www.test.com.url
初始化为：5个用户
每次增加：3个用户
运行：4次
每个客户端之间的延迟为：1秒
输出样例和siege一致，但是会在每一次增量结束之后都有输出。
3.测试方法说明
测试步骤：
方法1.安装apache2后，直接使用apache2的默认设置配置，不做任何修改，进行测试；
方法2.按照以前文档提出的Web容量规划和内存的大小，计算出相应的启动进程数，配置httpd.conf文件，再进行测试；
ServerLimit 400
StartServers 20
MinSpareServers 20
MaxSpareServers 50
MaxClients 300
MaxRequestsPerChild 10000
方法3.超过极限设置，进行测试。(规划容量的2倍进行)
1000个链接，分为不同的并发数请求，10、50、100、200、300、500
ab测试:
/usr/local/apache2.53/bin/ab -n 1000 -c 10 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 50 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 100 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 200 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 300 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 500 http://10.5.3.122/test/google.php/
siege测试:
/usr/local/siege/bin/siege -c 10 -r 100 -f www.test.com.url
/usr/local/siege/bin/siege -c 50 -r 20 -f www.test.com.url
/usr/local/siege/bin/siege -c 100 -r 10 -f www.test.com.url
/usr/local/siege/bin/siege -c 200 -r 5 -f www.test.com.url
/usr/local/siege/bin/siege -c 300 -r 3 -f www.test.com.url
/usr/local/siege/bin/siege -c 500 -r 2 -f www.test.com.url
增量测试:
/usr/local/siege/bin/bombardment www.test.com.url 1 100 5 1
/usr/local/siege/bin/bombardment www.test.com.url 1 100 6 1
4.测试结果总结
ab测试:测试并发连接数在50~500的情况下，方法2比方法1性能略有提升，但是相差在10个并发连接数左右，并且方法1方法2在测试并发数100的情况下，实际并发数都相差无几。
siege测试:测试并发数从50之后直到500，性能都有提升，并且在测试并发数100、200、500的情况下，提升相差10~30个实际并发数。
bombardment测试:相差不大。本次测试的结果不太理想，性能的变化不显著，也不明显，可以所属于失败的测试结果。
分析原因：
1.本身硬件配置不高，所以默认设置和修改后的设置变化不明显，对性能的提升也明显不足；
2.负载情况太少，由于系统性能原因，增量测试都不能过大的进行，系统性能load average过高；
3.测试页面程序也太少，没有太大说服力。
网站性能测试报告模板
下载文件 (已下载 255 次)Apache 优化加速
[ 2009/04/08 23:22 | by selboo ]
站点描述：
全静态页面，站点数据大小250M左右。
内存：4G
内存使用率才：10％都不到
解决方案;
本机加个SQUID做加速。个人感觉意义不大。
然后，看了下apache cookbook有个叫mem_cahce的模块。想尝试下呵呵。
使用mem_cache模块，编译apache时候必须添加
"--enable-cache"
"--enable-mem-cache"
或者使用apxs -ica 添加模块
mod_mem_cache需要mod_cache模块的支持。
mem_cache 简单应用：
CODE:
CacheEnable mem /
MCacheSize 262144
MCacheMaxObjectCount 10000
MCacheMinObjectSize 1
MCacheMaxObjectSize 1000000
MCacheRemovalAlgorithm LRU
CacheEnable mem / #需要存储的目录。
MCacheSize 262144 #cache使用内存的最大数量（kbyte）
MCacheMaxObjectCount 10000 #允许在cache中存储的最大数量
MCacheMinObjectSize 1 #最小允许在cache中存储文件的字节数(byte)
MCacheMaxObjectSize 1000000 #最大允许在cache中存储文件的字节书(byte)
MCacheRemovalAlgorithm LRU #文件在cache中使用的算法(默认GDSF)
详细配置请参考：
http://httpd.apache.org/docs/2.2/mod/mod_cache.html
http://httpd.apache.org/docs/2.2/mod/mod_mem_cache.html
http://httpd.apache.org/docs/2.2/caching.html#inmemory
全静态页面，站点数据大小250M左右。
内存：4G
内存使用率才：10％都不到
解决方案;
本机加个SQUID做加速。个人感觉意义不大。
然后，看了下apache cookbook有个叫mem_cahce的模块。想尝试下呵呵。
使用mem_cache模块，编译apache时候必须添加
"--enable-cache"
"--enable-mem-cache"
或者使用apxs -ica 添加模块
mod_mem_cache需要mod_cache模块的支持。
mem_cache 简单应用：
CODE:
CacheEnable mem /
MCacheSize 262144
MCacheMaxObjectCount 10000
MCacheMinObjectSize 1
MCacheMaxObjectSize 1000000
MCacheRemovalAlgorithm LRU
CacheEnable mem / #需要存储的目录。
MCacheSize 262144 #cache使用内存的最大数量（kbyte）
MCacheMaxObjectCount 10000 #允许在cache中存储的最大数量
MCacheMinObjectSize 1 #最小允许在cache中存储文件的字节数(byte)
MCacheMaxObjectSize 1000000 #最大允许在cache中存储文件的字节书(byte)
MCacheRemovalAlgorithm LRU #文件在cache中使用的算法(默认GDSF)
详细配置请参考：
http://httpd.apache.org/docs/2.2/mod/mod_cache.html
http://httpd.apache.org/docs/2.2/mod/mod_mem_cache.html
http://httpd.apache.org/docs/2.2/caching.html#inmemory
Web 服务器架构史
[ 2009/03/27 22:43 | by selboo ]
架构演变第一步：物理分离webserver和数据库
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；
