如何安装Siege并进行测试

在CentOS 5上面的过程。其它系统安装方式略有不同参照它的官方网站。

安装siege

yum -y install siege

配置siege

运行一次siege，它会在你的~目录创建一个.siegerc。你可以在里面修改你需要的东西。里面有说明，可以自己修改。需要说明的是里面有一个benchmark的属性，为false。siege不同于ab在于测试并发的时候请求也有个随机延迟，这样比较接近实际效果。

运行siege

一般用法：

siege -c 100 -r 10 -f someScript.url

-c是并发量，-r是重复次数。 url文件就是一个文本，每行都是一个url，它会从里面随机访问的。

类似ab的纯并发压力测试：

siege -c 100 -r 10 http://www.google.com

手册在此，因为siege很早就有，命令语法也变了很多，要么直接man siege，要么就看官方手册： http://www.joedog.org/Siege/Manual

== 关于sproxy === sproxy是用来录制siege脚本的代理工具。可是我没有在CentOS上调试成功，需要自己编译安装。好处是方便模拟post请求和cookie等，但是目前没有用到。 http://www.joedog.org/Sproxy/Manual

有时间的朋友看看这个slide：http://www.slideshare.net/Blaine/scaling-twitter，没有时间的看看我的摘要。

开发：
1、一定要测试！一定要早点测试！一定要早点测试！否则你就死定了。不要存任何侥幸心理，从项目的开始就写好测试。
2、对任何部分都要测试。还是测试！
3、性能测试要交给用户来做。那样才有意义。所以要做好log。用好分析工具：Munin（服务器内存占用监控）、Nagios（服务器服务网络状态监控）、AWStats & Google Analytics、错误日志、发现了错误马上进入问题跟踪系统（Trac、Jira……太多了，但是最好有一个）。

架构：
1、使用可以分区的架构。按照架构上的功能清晰的分区。这意味着你可以通过替换一个实现来改进性能，因为性能和复杂度往往是不可兼得的。

对于数据库：
1、尽量不要分布式数据库，包括数据库分区。最好通过提高单台服务器的性能提升这个节点的性能。更重要的是查询优化。通过备份服务器解决单点故障。
2、对where子句中的字段增加index。（这个当然了）
3、扁平化查询，比如一个user有很多朋友，查一个人的朋友如果通过外键会浪费很多性能。可以把ids序列化为1,2,3这样，然后用like查询速度更快。
4、一定要优化你的SQL，不要寄希望于ORM给你解决（不管是DataMapper、ActiveRecord或者UnitOfWork）。

Cache：
1、一定要考虑Cache，最重要的是领域对象的Cache，一定要考虑Memcache，如Memcached。
2、应该有90%的查询可以Cache。
3、但是要注意Cache实效问题（要及时标注实效），这个是个难点也是个重点。
4、可以考虑用Message来标记实效（这样可以保证异步，无阻塞的按照顺序的让数据失效），据称也不是很难。

Messaging：
1、混合应用。不用去看Java的OpenFire了，即使它很好，完全可以考虑erlang的ejabberd了，俄罗斯的产物。
2、排队问题有很多解决方案：ActiveMQ、RabbitMQ、MySQL + Lightweight Locking、Drb（for ruby）

一位ID是jackson1225的网友在javaeye询问了一个大型Web系统的架构和部署选型问题，希望能提高现有的基于Java的Web应用的服务能力。由于架构模式和部署调优一直是Java社区的热门话题，这个问题引发了很多热心网友的讨论，其中一些意见对其它大型Web项目也有很好的指导意义。在讨论之初jackson1225这样描述了当前的应用的架构和部署方案：

目前系统架构如下:

1. web层采用struts+tomcat实现，整个系统采用20多台web服务器，其负载均衡采用硬件F5来实现；
2. 中间层采用无状态会话Bean+DAO+helper类来实现，共3台weblogic服务器，部署有多个EJB，其负载均衡也采用F5来实现；
3. 数据库层的操作是自己写的通用类实现的，两台ORACLE数据库服务器，分别存放用户信息和业务数据；一台SQL SERVER数据库，是第三方的业务数据信息；

web层调用EJB远程接口来访问中间件层。web层首先通过一个XML配置文件中配置的EJB接口信息来调用相应的EJB远程接口；

该系统中一次操作涉及到两个ORACLE库以及一个SQL SERVER库的访问和操作，即有三个数据库连接，在一个事务中完成。

这样的架构其实很多公司都在使用，因为Struts和Tomcat分别是最流行的Java Web MVC框架和Servlet容器，而F5公司的负载均衡是横向扩展常见的解决方案（例如配置session sticky方案）。由于这个系统中有跨数据源的事务，所以使用Weblogic Server EJB容器和支持两阶段提交的数据库驱动就可以保证跨数据源的事物完整性（当然，容器管理的分布式事务并非是唯一和最优的解决方案）。

但是随着Rod Johnson重量级的著作《J2EE Development without EJB》和其中的Spring框架的流行，轻量级框架和轻量级容器的概念已经深入人心。所以对于jackson1225提出的这个场景，大多数网友都提出了置疑，认为这个系统滥用了技术，完全是在浪费钱。网友们大都认为SLSB（无状态会话Bean）完全没有必要出现在这个场景中，认为SLSB通过远程接口访问本地资源会有很大的性能开销，这种观点也是Rod johnson在without EJB中批判EJB 2.x中的一大反模式。

由于JavaEE是一个以模式见长的解决方案，模式和架构在JavaEE中占有很重要的地位，所以很多业内专家也都警惕“反模式（Anti-patterns）”的出现。对于上面所述的方案是否是反模式，jackson1225马上站出来申辩：

我们项目就是把EJB作为一个Facade，只是提供给WEB层调用的远程接口，而且只用了无状态会话Bean，所以性能上还可以的。

这个解释很快得到了一些网友的认可，但是大家很快意识到架构的好坏决定于是否能够满足用户的需求，davexin（可能是jackson1225的同事）描述了这个系统的用户和并发情况：

现在有用户4000万，马上要和另一个公司的会员系统合并，加起来一共有9000万用户。数据量单表中有一亿条以上的数据。这是基本的情况，其实我觉得现在的架构还是可以的，现在支持的并发大概5000并发用户左右，接下来会进行系统改造，目标支持1万个并发用户。

具体的并发量公布后又有网友置疑这个数据，认为这个系统的Servlet容器支持的并发数太小，怀疑是否配置不够优化。davexin又补充了该项目的服务器配置：

系统前端tomcat都是用的刀片，配置在2G内存，cpu大概在2.0G，每台机器也就支持250-400个并发，再多的话，就会相应时间非常的常，超过20秒，失去了意义 ，所以我们才得出这样的结论的。

一位ID是cauherk的网友提出了比较中肯的意见，他没有从Web容器单纯的并发支持能力上提出改进方案，而是提出了对于类似的应用的一些通用的改进提示，这里摘要一下：

1. 数据库压力问题

   可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。

2. 事务问题

   要在两个数据库中操作，那么必须考虑到分布式事务。你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，毕竟commit失败的几率很低。

3. web的优化

   将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存， google很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力。

   对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。

4. 网络问题

   可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。

cauherk的这个分析比较到位，其中ETags的方案是最近的一个热点，InfoQ的“使用ETags减少Web应用带宽和负载”里面对这种方案有很详细的介绍。一般以数据库为中心的Web应用的性能瓶颈都在数据库上，所以cauherk把数据库和事务问题放到了前两位来讨论。但是davexin解释在所讨论的这个项目中数据库并非瓶颈：

我们的压力不在数据库层，在web层和F5。 当高峰的时候 ，F5也被点死了，就是每秒点击超过30万，web动态部分根本承受不了。根据我们程序记录，20台web最多承受5000个并发，如果再多，tomcat就不响应了。就像死了一样。

这个回复让接下来的讨论都集中于Web容器的性能优化，但是JavaEye站长robbin发表了自己的意见，将话题引回了这个项目的架构本身：

performance tuning最重要的就是定位瓶颈在哪里，以及瓶颈是怎么产生的。

我的推测是瓶颈还是出在EJB远程方法调用上！

tomcat上面的java应用要通过EJB远程方法调用，来访问weblogic上面的无状态SessionBean，这样的远程方法调用一般都在100ms~500ms级别，或者更多。而如果没有远程方法调用，即使大量采用spring的动态反射，一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。一次web请求需要过长的执行时间，就会导致servlet线程被占用更多的时间，从而无法及时响应更多的后续请求。

如果这个推测是成立的话，那么我的建议就是既然你没有用到分布式事务，那么就干脆去掉EJB。weblogic也可以全部撤掉，业务层使用spring取代EJB，不要搞分布式架构，在每个tomcat实例上面部署一个完整的分层结构。

另外在高并发情况下，apache处理静态资源也很耗内存和CPU，可以考虑用轻量级web server如lighttpd/litespeed/nginx取代之。

robbin的推断得到了网友们的支持，davexin也认同robbin的看法，但是他解释说公司认为放弃SLSB存在风险，所以公司倾向于通过将Tomcat替换为Weblogic Server 10来提升系统的用户支撑能力。robbin则马上批评了这种做法：

坦白说我还从来没有听说过大规模互联网应用使用EJB的先例。为什么大规模互联网应用不能用EJB，其实就是因为EJB性能太差，用了EJB几乎必然出现性能障碍。

web容器的性能说到底无非就是Servlet线程调度能力而已，Tomcat不像WebLogic那样附加n多管理功能，跑得快很正常。对比测试一下WebLogic的数据库连接池和C3P0连接池的性能也会发现类似的结论，C3P0可要比WebLogic的连接池快好几倍了。这不是说WebLogic性能不好，只不过weblogic要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。

以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEA JRockit JVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。

接下来robbin还针对davexin对话题中的应用分别在tomcat和weblogic上的测试数据进行了分析：

引用：

2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户......
......
4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。

这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？只有两个可能的原因：

1. 你的tomcat没有配置好，严重影响了性能表现
2. tomcat和weblogic之间的接口出了问题

 

接着springside项目发起者江南白衣也提出了一个总体的优化指导：

1.基础配置优化

tomcat 6？ tomcat参数调优?
JRockit JVM? JVM参数调优？
Apache+Squid 处理静态内容？

2.业务层优化

部分功能本地化，而不调remote session bean?
异步提交操作,JMS？
cache热点数据？

3.展示层优化

动态页面发布为静态页面？
Cache部分动态页面内容？

davexin在调整了Tomcat配置后应验了robbin对tomcat配置问题的质疑，davexin这样描述经过配置优化以后的测试结果：

经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。

至此这个话题有了一个比较好的结果。这个话题并非完全针对一个具体的项目才有意义，更重要的是在分析和讨论问题的过程中网友们解决问题的思路，尤其是cauherk、robbin、江南白衣等几位网友提出的意见可以让广大Java Web项目开发者了解到中、大型项目所需要考虑的架构和部署所需要考虑的关键问题，也消除了很多人对轻量Servlet容器与EJB容器性能的一些误解。

在讨论中还有一些小插曲，如davexin和江南白衣讨论了JRocket的实时（Realtime）版本是否可以提升Servlet容器的相应能力，答案是不可以。还有ID为mfc42d的网友从Servlet容器的并发支持能力引申到了Java的线程调度能力和NIO对Servelet容器的意义，他推荐了自己的两篇不错的blog“java的线程实现”和“java进程使用的最大内存的数值”，blog文章里面从JVM源码级别分析了Java的线程支持能力，面临JVM性能调优问题的网友可以认真阅读一下。

javaeye的hax最近在他的blog上进行了一场关于如何写css的讨论，其中反思和讨论了一些关于基于标准或trick进行设计的选择问题，这个问题也是David Heinemeier Hansson对于XHTML/CSS/Javascript标准进行RIA开发话题的一个延展。我们可以从中思考如何在不完美的技术中选择一条相对完美的技术路线？

讨论的起因是淘宝网的UED团队成员段王爷在他的blog上发表了一篇关于淘宝网页面设计上的小技巧（Trick）的介绍，这个技巧是为了让一些条目之间的分隔线完全使用css生成，不使用多余的class，段王爷还对比了其它三种常见实现方法。实现方法如下：

从很久很久以前开始，类目间的横线无非都只有三种。
1、背景图
在a标签设置一个padding 用宽1px高不等的背景图来position到右侧。
缺点：最后一个还是要用class来隐藏掉背景。
2、符号
在每个a标签之间用“|”符号来填充。
缺点：html文件变大，文件维护变得很麻烦，而且在html中毫无意义。
3、a标签右侧的boder。
同背景图一样，只不过使用border-right来代替。缺点也同上。

其实现有（淘宝的实现方式）是利用ul的overflow:hidden 再将li的margin-left:-1px的做法做出来的。这样的做法就可以同时避免以上的缺点了。

上面提到的使用border的传统方式需要在第一或者最后一个元素上面添加class来隐藏border，Realazy也在他的blog中给出了一种不错的解决方案，他推荐这样做：

导航项目间的竖线，我们往往通过border或者background来实现。特殊需求是，第一项左边无竖线或最后一项右边无竖线。按照一般的编程方法，控制第一项要比控制最后一项容易得多。

区分第一项的还有一个好处是，CSS有一个:first-child的伪元素（pseudo element）可以让我们轻而易举的选择第一个子元素。遗憾的是，当前全球占有率最高的浏览器，IE6，并不支持这个伪元素。我们可以手工给第一个元素加上class然后再定义它。等ie6淘汰之时，就可以放心用 :first-child了，相权衡的话，我觉得给第一项加上class="first"也不失为实用主义做法。

Realazy提出的方案的思路是使用基于标准的css选择器（selector），这种方法的好处是可以实现完美的内容与表现分离。但是现实的问题是并非所有的浏览器都基于标准实现，这也正是基于标准的RIA开发面对的最大问题，尤其以CSS和Javascript问题最大。javaeye的hax在他的blog中提出了自己对于这个Trick的不同意见：

因为我觉得这个方法一点也不好。很简单的一个理由：这只是一个trick，只适合这特殊情况，假设你要换用“-”来分割呢？作为插入分割符号来说，真正合理使用css的，我给一个例子：
li ~ li:before { content:'-'; margin:0.25em; }

优点：含义非常清晰，维护性极高。你可以换任何的分隔字符，可以设定字体，可以设定颜色、大小等样式，甚至可以换用图片作为分隔。

好了，下面说缺点。唯一的缺点：IE不支持。

hax给出的方案在IE中无法使用，其实对于大部分网站来说这就相当于绝大多数用户都无法看到这种表现，这就意味着失败。淘宝UED的小马提出“实用第一”，从这种观点上说hax的方案就是不实用的。但是hax提出可以使用Dean Edwards的IE7 Javascript库：

IE7是一个可以让IE像标准浏览器一样工作的Javascript库。它修正了很多CSS问题，让PNG在IE5和IE6下正常工作。

IE7这个库动态的实现了很多IE原本不支持的伪类（Pseudo Classes），让完全基于标准的css选择器（使用伪类）成为可能。随后，hax在他的另外一篇blog“面向未来的CSS实践”中作了如下设想：

我推崇一种面向未来的CSS实践。即大胆采用CSS2.1甚至部分CSS3的特性。因为绝大多数特性，Firefox、Opera、 Safari等都已经很好的支持了。MSIE7也改进了许多，将来IE也无疑终究会完全支持CSS2.1。对于目前的IE，除了graceful degradation的方式（实际上整个内容样式分离的原则和良好的CSS设计可以确保这点，比如淘宝以前的“裸体”所体现的），可以考虑通过特定手段来patch之。

在这点上，我必须说，我原来也是一直坚持只用ie6的selector的。是什么改变了我？就是Dean Edwards的IE7！它的出现不仅在于实践价值——即提供了一个对于IE的补丁，让开发者可以直接写CSS2甚至CSS3。

hax提出的这种方式是比较激进的，他还在“面向未来的CSS实践”中进一步的描述了通过脚本修正的方式解决IE不支持标准伪类和多class问题的设想，他的核心想法就是让CSS的开发可以遵循标准，减少为了优雅退化（graceful degradation）而向最低支持（浏览器）兼容造成的表达方式限制。但是hax自己也提出了这种思路面临的尴尬，它举了table布局的实用性价值为例：

我认为出现这样讽刺的情况，即遵循标准的人活得比不遵循的人更累，是很有问题的。这种矛盾在我身上存在着，2001年的时候我在某bbs上发了个贴，大数 table布局之罪，但是过了几天我又跑上去说table布局在某种情况下也可以用用。 dlee同志貌似到现在也跟我当时一样。如果你确实认为，table布局从实用主义角度无法被完全否定，那DHH同志采用实用主义的角度来力挺 html/css/js就也有点心虚，那个标题也就显得带点任性味道……

“遵循标准的人活得比不遵循的人更累”这句话说出了很多坚持基于标准进行CSS设计的开发人员的心声，这其实是实用性和坚持标准之间的一些交换，现实世界中两个方面如何平衡正是广大XHTML/CSS/Javascript开发者需要认真思考的，关键的问题，还是目的要明确。盲目的遵循标准，例如很多开发者着迷于使用div布局代替table，但是却没有明确的目标就会迷失，hax这样评价：

从实用主义角度说，谨慎的table布局也许更简单，因为它更好的映射到了grid模型上。如果你转用div/span，标签是清晰了，但是css是混乱的！这些属性（css属性）是分散的，css代码无法反映整体，无法记录你的grid 布局意图！这是为什么我们经常说我有一个css trick的原因，它是trick而已，是你达到最终目的的手段，但是你的目的，你的意图，没有好好加入文档的话，那维护起来恐怕也不见得轻松。

table布局 其他css样式 = 清晰的布局意图和内容的混合体

div容器 css样式 = 内容样式分离，但是从css代码中很难看出布局意图

关于div/css布局还有一些误区，简单的把table标签换成div是没有意义的（若干层级的div可能比table更糟糕）。实际上我们希望的是语义标签。

我们应该看到，CSS的意图是将表现分离。从设计的角度就是实现语义化的html结构，让html/xhtml尽量只表达纯粹的数据结构。但是此时css里面的布局意图是比较难以被记录的（难以被理解就难以维护，难以重构），有其在充斥了大量Trick的情况下，这正是广大程序员/设计人员需要解决的，我们是否应该通过不断地重构来找到这个矛盾的平衡点呢？欢迎大家讨论。最后附上淘宝UED团队的小马总结的淘宝CSS编程原则：

1. 尽量不使用hack
2. 尽量不使用ie6不支持的选择符

能符合这两个条件的最简洁的写法，就是我们的目标。

思考一下，其实就是当下流行的mush up。你混合一下你的长处，也许你就找到了你真正的长处，你的职业。
同时James又推荐了Stay Hungry，Stay Foolish，他说他37岁了依然觉得那是篇很好的文章。我很早之前也推荐过这篇文章，大家继续看看。