海量小文件系统架构方案
[ 2009/12/14 08:24 | by selboo ]
现在的网站越做越大了，存储的东西越来越多，如何解决这些文件存储也成了新的难题。如果把这些文件都完全采用大硬盘存储来解决，并不是一个好主意，因为数据量越大风险就越高，虽然文件能存得下，但是故障率相应会较高，另外重建耗费时间也比较长。所以最好的办法是尽可能考虑分布式存储，把文件想办法利用网络分散到多个机器上。
从我所了解的存储结构来看，分布式存储大致可以分为几种：
1、类googlefs的分布式文件系统
因为目前googlefs没有开源，所以网上出现的分布式文件系统都是利用google的方案自行实现的。这个方案的优点是可用性比较高，基本上基于硬盘的应用都可以处理，可用范围就比较广泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相关介绍，大致有一些认识。
首先是文档比较少而出现的问题倒不少；然后是目前这些还没有一个能称得上是稳定版本，如果有的话，估计也就是其中一些收费的版本。因为磁盘存储乃是致关重要，所以目前建议还是不要轻易把这些东西部署到重要的地方。假如非常想使用的话，最好是做好充分测试，确保它的功能完全能够满足需要；然后还要想办法在传统的文件系统中做好完全的备份，以免造成损失。
另外可以提的一个东西是memcached，这个东西实现了内存的分布式共享，稳定度貌似比以上这些分布式文件系统要稳定。不过是完全基于内存的，如果数据量不是很大，可以一试。
2、手工使用文件路径分散存储
这个结构通常使用在web静态文件中，就以这种情形作为例子。
如果这些文件数量比较大，可以通过分散文件路径，把某个文件的访问指定到特定的一台或几台服务器上。例如：
1)采用域名的分散策略
例如使用a.xxx.com/b.xxx.com…来区分标记为a或b的一系列文件，这些文件存储的时候，依然按照标记，存到a或b的服务器上。这个策略将区分机器的任务交由dns服务器来执行，扩容时会相应轻松。这需要web项目初期就规划好这些东东，后期才转用域名策略的成本比较高甚至不可以实现。
2)采用目录的分散策略
假如域名初期并没有规划使用域名策略，那么可以采用代理服务器来进行目录级的划分。比如一般存储大量文件时，因为文件系统的限制以及效率问题，都会按照一定规则划分了很多级的目录，按这些目录拆分机器也并不是困难的事情。这种架构的问题在于代理服务器的性能和可靠性问题，需要在这点上稍下一点功夫。
以上这两个方案，都要自行制定策略实现分散同步传输，传输一般可以归纳为推送和抓取两种办法，同步的话可以采用日志同步（把要同步的数据记入日志，通过日志记录来传输相应文件）、比较同步（使用rsync等同步软件）或即时同步（有新的修改就立刻传输）；另外要实现单点故障剔除的话，首先找一个策略把文件存储到多个节点上，例如，a.xxx.com或目录a的文件相应也存到b和c节点；然后在环境中使用故障剔除技术（lvs或nginx等），就可以解决问题，例如：采用域名的话，可以采用lvs，缺点是使用的机器就会成倍增加；亦可再用一级代理服务器，缺点是会牺牲性能。采用目录的话，因为本身就用到了代理服务器，所以只要存储得当，实现比较容易。
从我所了解的存储结构来看，分布式存储大致可以分为几种：
1、类googlefs的分布式文件系统
因为目前googlefs没有开源，所以网上出现的分布式文件系统都是利用google的方案自行实现的。这个方案的优点是可用性比较高，基本上基于硬盘的应用都可以处理，可用范围就比较广泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相关介绍，大致有一些认识。
首先是文档比较少而出现的问题倒不少；然后是目前这些还没有一个能称得上是稳定版本，如果有的话，估计也就是其中一些收费的版本。因为磁盘存储乃是致关重要，所以目前建议还是不要轻易把这些东西部署到重要的地方。假如非常想使用的话，最好是做好充分测试，确保它的功能完全能够满足需要；然后还要想办法在传统的文件系统中做好完全的备份，以免造成损失。
另外可以提的一个东西是memcached，这个东西实现了内存的分布式共享，稳定度貌似比以上这些分布式文件系统要稳定。不过是完全基于内存的，如果数据量不是很大，可以一试。
2、手工使用文件路径分散存储
这个结构通常使用在web静态文件中，就以这种情形作为例子。
如果这些文件数量比较大，可以通过分散文件路径，把某个文件的访问指定到特定的一台或几台服务器上。例如：
1)采用域名的分散策略
例如使用a.xxx.com/b.xxx.com…来区分标记为a或b的一系列文件，这些文件存储的时候，依然按照标记，存到a或b的服务器上。这个策略将区分机器的任务交由dns服务器来执行，扩容时会相应轻松。这需要web项目初期就规划好这些东东，后期才转用域名策略的成本比较高甚至不可以实现。
2)采用目录的分散策略
假如域名初期并没有规划使用域名策略，那么可以采用代理服务器来进行目录级的划分。比如一般存储大量文件时，因为文件系统的限制以及效率问题，都会按照一定规则划分了很多级的目录，按这些目录拆分机器也并不是困难的事情。这种架构的问题在于代理服务器的性能和可靠性问题，需要在这点上稍下一点功夫。
以上这两个方案，都要自行制定策略实现分散同步传输，传输一般可以归纳为推送和抓取两种办法，同步的话可以采用日志同步（把要同步的数据记入日志，通过日志记录来传输相应文件）、比较同步（使用rsync等同步软件）或即时同步（有新的修改就立刻传输）；另外要实现单点故障剔除的话，首先找一个策略把文件存储到多个节点上，例如，a.xxx.com或目录a的文件相应也存到b和c节点；然后在环境中使用故障剔除技术（lvs或nginx等），就可以解决问题，例如：采用域名的话，可以采用lvs，缺点是使用的机器就会成倍增加；亦可再用一级代理服务器，缺点是会牺牲性能。采用目录的话，因为本身就用到了代理服务器，所以只要存储得当，实现比较容易。
nginx图片服务器的架构方案
[ 2009/12/14 08:23 | by selboo ]
图片服务通常数据容量较大，而且访问也频繁，鉴于此，图片服务就会有两种问题，一是存储问题，二是访问量问题。
存储问题就是硬盘容量问题，花钱买硬盘就可以了，看似简单，但着实也是最苦的问题。按目前探索来看，最好的方式是：在任何时刻遇到硬盘空间不够时，买颗硬盘插上，最多改改配置，就能立刻利用；另外，硬盘要能充分利用，不然图片存储量大再加上备份，很恐怖，最好是每颗硬盘都用上100%的空间。
访问量也是个大问题，如果服务不允许防盗链，那么访问量会引起带宽、服务器压力等问题，有钱的话直接扔CDN，没钱或者有更多的钱，就自己做吧。根据垣古不变的真理“越老的图，访问量也相对较少”这一点，分成两大部分，一边处理最新的图片，一边处理老旧的图片。最新的图片访问量大，但存储量较少；老图片访问量低，但存储量大。
大概分析完了，开始制定方案。
一、拟定一个存储目录规则：
在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成：/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定这个目录规则后，就可以按年月来拆机器了。
二、分机器，分硬盘
按之前的计划，分成两个组，一组服务器用lvs做负载均衡负责新图片；另一组服务器做旧图片访问和备份。新图机器找几台好点的服务器，SCSI硬盘；旧图机器没太大要求，PC机就行，找够硬盘就可以，现在IDE的1T硬盘也不太贵，最好再搭个raid就省事了，最主要是这些机器要多。
照这个图，搭一搭
说明一下：
1、图片服务通过lvs作为入口，处理能力上还是有保障的。
2、利用nginx直接对外服务，不必用squid。
3、图中的红线是指主nginx会将/2006和/2007年的图片分别代理到两台存档服务器，如果发现主nginx的cpu占用比较大，那么可以考虑使用nginx的proxy_store将图片存到主服务器上，定期清理。
4、图中有一台存储分配服务器，作为图片服务更新图片的统一入口，有新图片或者修改图片的话，由这台服务器负责将图片放到正确的服务器上去。
5、旧图片服务器当前用年份来划分，每年增加两台服务器，亦可是加两块硬盘，注意，不要相信raid，一定要有两台机器，地理上分在两个城市则更好。
6、因为旧数据2006和2007年的数据基本上是没有变化的，所以假如硬盘够大，那么可以把两年的数据合并在一起。
7、如果细心定制，那么旧图片服务器的硬盘100%塞满是可以的，旧数据的容量基本上不会大幅增长，小小预留1-2G空间就可以了。
使用这个架构的话，到了2009年，我会把2008年的数据想办法迁到旧图服务器上，硬盘不够的话，加硬盘就可以了。如果图片量实在太大，主服务器连一年的数据都装不下，那可以用启用月份来划分；如果一个月都装不下了，那也太夸张了，那就启用日期吧；如果一天的数据都装不下，那就◎＃￥％……※。
存储问题就是硬盘容量问题，花钱买硬盘就可以了，看似简单，但着实也是最苦的问题。按目前探索来看，最好的方式是：在任何时刻遇到硬盘空间不够时，买颗硬盘插上，最多改改配置，就能立刻利用；另外，硬盘要能充分利用，不然图片存储量大再加上备份，很恐怖，最好是每颗硬盘都用上100%的空间。
访问量也是个大问题，如果服务不允许防盗链，那么访问量会引起带宽、服务器压力等问题，有钱的话直接扔CDN，没钱或者有更多的钱，就自己做吧。根据垣古不变的真理“越老的图，访问量也相对较少”这一点，分成两大部分，一边处理最新的图片，一边处理老旧的图片。最新的图片访问量大，但存储量较少；老图片访问量低，但存储量大。
大概分析完了，开始制定方案。
一、拟定一个存储目录规则：
在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成：/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定这个目录规则后，就可以按年月来拆机器了。
二、分机器，分硬盘
按之前的计划，分成两个组，一组服务器用lvs做负载均衡负责新图片；另一组服务器做旧图片访问和备份。新图机器找几台好点的服务器，SCSI硬盘；旧图机器没太大要求，PC机就行，找够硬盘就可以，现在IDE的1T硬盘也不太贵，最好再搭个raid就省事了，最主要是这些机器要多。
照这个图，搭一搭
说明一下：
1、图片服务通过lvs作为入口，处理能力上还是有保障的。
2、利用nginx直接对外服务，不必用squid。
3、图中的红线是指主nginx会将/2006和/2007年的图片分别代理到两台存档服务器，如果发现主nginx的cpu占用比较大，那么可以考虑使用nginx的proxy_store将图片存到主服务器上，定期清理。
4、图中有一台存储分配服务器，作为图片服务更新图片的统一入口，有新图片或者修改图片的话，由这台服务器负责将图片放到正确的服务器上去。
5、旧图片服务器当前用年份来划分，每年增加两台服务器，亦可是加两块硬盘，注意，不要相信raid，一定要有两台机器，地理上分在两个城市则更好。
6、因为旧数据2006和2007年的数据基本上是没有变化的，所以假如硬盘够大，那么可以把两年的数据合并在一起。
7、如果细心定制，那么旧图片服务器的硬盘100%塞满是可以的，旧数据的容量基本上不会大幅增长，小小预留1-2G空间就可以了。
使用这个架构的话，到了2009年，我会把2008年的数据想办法迁到旧图服务器上，硬盘不够的话，加硬盘就可以了。如果图片量实在太大，主服务器连一年的数据都装不下，那可以用启用月份来划分；如果一个月都装不下了，那也太夸张了，那就启用日期吧；如果一天的数据都装不下，那就◎＃￥％……※。
2009系统架构师大会演讲PPT
[ 2009/09/03 16:18 | by selboo ]
http://linux.chinaunix.net/SACC2009/SACC2009_AppServer.rar
http://linux.chinaunix.net/SACC2009/SACC2009_database.rar
http://linux.chinaunix.net/SACC2009/SACC2009_education.rar
http://linux.chinaunix.net/SACC2009/SACC2009_monitor.rar
http://linux.chinaunix.net/SACC2009/SACC2009_network.rar
http://linux.chinaunix.net/SACC2009/SACC2009_Storage.rar
http://linux.chinaunix.net/SACC2009/SACC2009_SystemArch.rar
LAMP网站架构方案分析
[ 2009/08/31 15:26 | by selboo ]
LAMP（Linux-Apache-MySQL-PHP）网站架构是目前国际流行的Web框架， 该框架包括：Linux操作系统，Apache网络服务器，MySQL数据库，Perl、PHP或者Python编程语言，所有组成产品均是开源软件，是 国际上成熟的架构框架，很多流行的商业应用都是采取这个架构，和Java/J2EE架构相比，LAMP具有Web资源丰富、轻量、快速开发等特点，微软 的.NET架构相比，LAMP具有通用、跨平台、高性能、低价格的优势，因此LAMP无论是性能、质量还是价格都是企业搭建网站的首选平台。
对于大流量、大并发量的网站系统架构来说，除了硬件上使用高性能的服务器、负载均衡、CDN等之外，在软件架构上需要重点关注下面几个环节：使用高性能 的操作系统（OS）、高性能的网页服务器（Web Server）、高性能的数据库（Databse）、高效率的编程语言等。下面我将从这几点对其一一讨论。
操作系统
Linux操作系统有很多个不同的发行版，如Red Hat Enterprise Linux、SUSE Linux Enterprice、Debian、Ubuntu、CentOS等，每一个发行版都有自己的特色，比如RHEL的稳定，Ubuntu的易用，基于稳定性 和性能的考虑，操作系统选择CentOS（Community ENTerprise Operating System）是一个理想的方案。
CentOS（Community ENTerprise Operating System）是Linux发行版之一，是RHEL/Red Hat Enterprise Linux的精简免费版，和RHEL为同样的源代码，不过，RHEL和SUSE LE等企业版，提供的升级服务均是收费升级，无法免费在线升级，因此要求免费的高度稳定性的服务器可以用CentOS替代Red Hat Enterprise Linux使用。
Web服务器、缓存和PHP加速
Apache是LAMP架构最核心的Web Server，开源、稳定、模块丰富是Apache的优势。但Apache的缺点是有些臃肿，内存和CPU开销大，性能上有损耗，不如一些轻量级的Web 服务器（例如nginx）高效，轻量级的Web服务器对于静态文件的响应能力来说远高于Apache服务器。
Apache做为Web Server是负载PHP的最佳选择，如果流量很大的话，可以采用nginx来负载非PHP的Web请求。nginx是一个高性能的HTTP和反向代理服 务器，Nginx以它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。Nginx不支持Windows，只能在包括Linux等环境下安 装，也不支持PHP和CGI等，但支持负载均衡和容错，可和Apache配合使用，是轻量级的HTTP服务器的首选。
Web服务器的缓 存也有多种方案，Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。 Squid Cache是一个Web缓存服务器，支持高效的缓存，可以作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度，把Squid放在 Apache的前端来缓存Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。如访问量巨大则可考虑使用memcache作 为分布式缓存。
PHP的加速使用eAccelerator加速器，eAccelerator是一个自由开放源码PHP加速器，优化和动 态内容缓存，提高了性能PHP脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。它还有对脚本起优化作用，以加快其执行效率。 使PHP程序代码执效率能提高1-10倍。
具体的解决方案有以下几种：
1、squid + Apache + PHP + eAccelerator
使用Apache负载PHP，使用squid进行缓存，html或图片的请求可以直接由squid返回给用户。很多大型网站都采用这种架构。
2、nginx/Apache + PHP（fastcgi） + eAccelerator
使用nginx或Apache负载PHP，PHP使用fastcgi方式运行，效率较高。
3、nginx + Apache + PHP + eAccelerator
此方案综合了nginx和Apache的优点，使用Apache负载PHP，nginx负责解析其他Web请求，使用nginx的rewrite模块，Apache端口不对外开放。
数据库
开源的数据库中，MySQL在性能、稳定性和功能上是首选，可以达到百万级别的数据存储，网站初期可以将MySQL和Web服务器放在一起，但是当访问 量达到一定规模后，应该将MySQL数据库从Web Server上独立出来，在单独的服务器上运行，同时保持Web Server和MySQL服务器的稳定连接。
当数据库访问量达到更大的级别，可以考虑使用MySQL Cluster等数据库集群或者库表散列等解决方案。
总的来说，LAMP架构的网站性能会远远优于Windows IIS + ASP + Access（例如月光博客）这样的网站，可以负载的访问量也非常大，国内的大量个人网站如果想要支撑大访问量，采用LAMP架构是一个不错的方案。
综上所述，基于LAMP架构设计具有成本低廉、部署灵活、快速开发、安全稳定等特点，是Web网络应用和环境的优秀组合。
对于大流量、大并发量的网站系统架构来说，除了硬件上使用高性能的服务器、负载均衡、CDN等之外，在软件架构上需要重点关注下面几个环节：使用高性能 的操作系统（OS）、高性能的网页服务器（Web Server）、高性能的数据库（Databse）、高效率的编程语言等。下面我将从这几点对其一一讨论。
操作系统
Linux操作系统有很多个不同的发行版，如Red Hat Enterprise Linux、SUSE Linux Enterprice、Debian、Ubuntu、CentOS等，每一个发行版都有自己的特色，比如RHEL的稳定，Ubuntu的易用，基于稳定性 和性能的考虑，操作系统选择CentOS（Community ENTerprise Operating System）是一个理想的方案。
CentOS（Community ENTerprise Operating System）是Linux发行版之一，是RHEL/Red Hat Enterprise Linux的精简免费版，和RHEL为同样的源代码，不过，RHEL和SUSE LE等企业版，提供的升级服务均是收费升级，无法免费在线升级，因此要求免费的高度稳定性的服务器可以用CentOS替代Red Hat Enterprise Linux使用。
Web服务器、缓存和PHP加速
Apache是LAMP架构最核心的Web Server，开源、稳定、模块丰富是Apache的优势。但Apache的缺点是有些臃肿，内存和CPU开销大，性能上有损耗，不如一些轻量级的Web 服务器（例如nginx）高效，轻量级的Web服务器对于静态文件的响应能力来说远高于Apache服务器。
Apache做为Web Server是负载PHP的最佳选择，如果流量很大的话，可以采用nginx来负载非PHP的Web请求。nginx是一个高性能的HTTP和反向代理服 务器，Nginx以它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。Nginx不支持Windows，只能在包括Linux等环境下安 装，也不支持PHP和CGI等，但支持负载均衡和容错，可和Apache配合使用，是轻量级的HTTP服务器的首选。
Web服务器的缓 存也有多种方案，Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。 Squid Cache是一个Web缓存服务器，支持高效的缓存，可以作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度，把Squid放在 Apache的前端来缓存Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。如访问量巨大则可考虑使用memcache作 为分布式缓存。
PHP的加速使用eAccelerator加速器，eAccelerator是一个自由开放源码PHP加速器，优化和动 态内容缓存，提高了性能PHP脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。它还有对脚本起优化作用，以加快其执行效率。 使PHP程序代码执效率能提高1-10倍。
具体的解决方案有以下几种：
1、squid + Apache + PHP + eAccelerator
使用Apache负载PHP，使用squid进行缓存，html或图片的请求可以直接由squid返回给用户。很多大型网站都采用这种架构。
2、nginx/Apache + PHP（fastcgi） + eAccelerator
使用nginx或Apache负载PHP，PHP使用fastcgi方式运行，效率较高。
3、nginx + Apache + PHP + eAccelerator
此方案综合了nginx和Apache的优点，使用Apache负载PHP，nginx负责解析其他Web请求，使用nginx的rewrite模块，Apache端口不对外开放。
数据库
开源的数据库中，MySQL在性能、稳定性和功能上是首选，可以达到百万级别的数据存储，网站初期可以将MySQL和Web服务器放在一起，但是当访问 量达到一定规模后，应该将MySQL数据库从Web Server上独立出来，在单独的服务器上运行，同时保持Web Server和MySQL服务器的稳定连接。
当数据库访问量达到更大的级别，可以考虑使用MySQL Cluster等数据库集群或者库表散列等解决方案。
总的来说，LAMP架构的网站性能会远远优于Windows IIS + ASP + Access（例如月光博客）这样的网站，可以负载的访问量也非常大，国内的大量个人网站如果想要支撑大访问量，采用LAMP架构是一个不错的方案。
综上所述，基于LAMP架构设计具有成本低廉、部署灵活、快速开发、安全稳定等特点，是Web网络应用和环境的优秀组合。
Siege：压力模拟/测试工具
[ 2009/08/23 12:55 | by selboo ]
Siege是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。
最早使用的压力测试工具是apache的ab(apache benchmark)，apache ab做重复压力测试不错，但是每次只能测试一个链接，如何测试一组链接（比如从日志中导出的1个小时的日志，做真实压力测试），后来找到了这个：
SIEGE is an http regressive testing and benchmarking utility. It was designed to let web developers measure the performance of their code under duress, to see how it will stand up to load on the internet. It lets the user hit a webserver with a configurable number of concurrent simulated users. Those users place the webserver “under siege.” The duration of the siege is measured in transactions, the sum of simulated users and the number of times each simulated user repeats the process of hitting the server. Thus 20 concurrent users 50 times is 1000 transactions, the length of the test.
下载/安装
Siege时一个开放源代码项目：http://www.joedog.org
下载：
wget ftp://sid.joedog.org/pub/siege/siege-latest.tar.gz
安装：
%./configure ; make
#make install
siege包含了一组压力测试工具：
SIEGE (1) Siege是一个HTTP压力测试和评测工具.
使用样例：
任务列表：www.chedong.com.url文件
http://www.chedong.com/tech/
http://www.chedong.com/tech/acdsee.html
http://www.chedong.com/tech/ant.html
http://www.chedong.com/tech/apache_install.html
http://www.chedong.com/tech/awstats.html
http://www.chedong.com/tech/cache.html
http://www.chedong.com/tech/click.html
http://www.chedong.com/tech/cms.html
http://www.chedong.com/tech/compress.html
http://www.chedong.com/tech/cvs_card.html
http://www.chedong.com/tech/default.html
http://www.chedong.com/tech/dev.html
http://www.chedong.com/tech/gnu.html
….
siege -c 20 -r 2 -f www.chedong.com.url
参数说明：
-c 20 并发20个用户
-r 2 重复循环2次
-f www.chedong.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 失败处理次数
注意：由于速度很快，可能会达不到并发速度很高就已经完成。Response time显示的是测试机器和被测试服务器之间网络链接状况。Transaction rate则表示服务器端任务处理的完成速度。
辅助工具：
增量压力测试：
为了方便增量压力测试，siege还包含了一些辅助工具：
bombardment (1)
是一个辅助工具：用于按照增量用户压力测试：
使用样例：
bombardment urlfile.txt 5 3 4 1
初始化URL列表：urlfile.txt
初始化为：5个用户
每次增加：3个用户
运行：4次
每个客户端之间的延迟为：1秒
输出成CSV格式：
siege2csv.pl (1)
siege2csv.pl将bombardment的输出变成CSV格式：
Time Data Transferred Response Time Transaction Rate Throughput Concurrency Code 200 (note that this is horribly broken.)
242 60.22 603064 0.02 4.02 10014.35 0.08
605 59.98 1507660 0.01 10.09 25136.05 0.12
938 59.98 2337496 0.02 15.64 38971.26 0.26
1157 60 2883244 0.04 19.28 48054.07 0.78
参考：
开源测试工具：http://www.opensourcetesting.org/performance.php
压力测试工具：HammerHead 正在试用中
最早使用的压力测试工具是apache的ab(apache benchmark)，apache ab做重复压力测试不错，但是每次只能测试一个链接，如何测试一组链接（比如从日志中导出的1个小时的日志，做真实压力测试），后来找到了这个：
SIEGE is an http regressive testing and benchmarking utility. It was designed to let web developers measure the performance of their code under duress, to see how it will stand up to load on the internet. It lets the user hit a webserver with a configurable number of concurrent simulated users. Those users place the webserver “under siege.” The duration of the siege is measured in transactions, the sum of simulated users and the number of times each simulated user repeats the process of hitting the server. Thus 20 concurrent users 50 times is 1000 transactions, the length of the test.
下载/安装
Siege时一个开放源代码项目：http://www.joedog.org
下载：
wget ftp://sid.joedog.org/pub/siege/siege-latest.tar.gz
安装：
%./configure ; make
#make install
siege包含了一组压力测试工具：
SIEGE (1) Siege是一个HTTP压力测试和评测工具.
使用样例：
任务列表：www.chedong.com.url文件
http://www.chedong.com/tech/
http://www.chedong.com/tech/acdsee.html
http://www.chedong.com/tech/ant.html
http://www.chedong.com/tech/apache_install.html
http://www.chedong.com/tech/awstats.html
http://www.chedong.com/tech/cache.html
http://www.chedong.com/tech/click.html
http://www.chedong.com/tech/cms.html
http://www.chedong.com/tech/compress.html
http://www.chedong.com/tech/cvs_card.html
http://www.chedong.com/tech/default.html
http://www.chedong.com/tech/dev.html
http://www.chedong.com/tech/gnu.html
….
siege -c 20 -r 2 -f www.chedong.com.url
参数说明：
-c 20 并发20个用户
-r 2 重复循环2次
-f www.chedong.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 失败处理次数
注意：由于速度很快，可能会达不到并发速度很高就已经完成。Response time显示的是测试机器和被测试服务器之间网络链接状况。Transaction rate则表示服务器端任务处理的完成速度。
辅助工具：
增量压力测试：
为了方便增量压力测试，siege还包含了一些辅助工具：
bombardment (1)
是一个辅助工具：用于按照增量用户压力测试：
使用样例：
bombardment urlfile.txt 5 3 4 1
初始化URL列表：urlfile.txt
初始化为：5个用户
每次增加：3个用户
运行：4次
每个客户端之间的延迟为：1秒
输出成CSV格式：
siege2csv.pl (1)
siege2csv.pl将bombardment的输出变成CSV格式：
Time Data Transferred Response Time Transaction Rate Throughput Concurrency Code 200 (note that this is horribly broken.)
242 60.22 603064 0.02 4.02 10014.35 0.08
605 59.98 1507660 0.01 10.09 25136.05 0.12
938 59.98 2337496 0.02 15.64 38971.26 0.26
1157 60 2883244 0.04 19.28 48054.07 0.78
参考：
开源测试工具：http://www.opensourcetesting.org/performance.php
压力测试工具：HammerHead 正在试用中
