分类： Java
2011-10-14 14:51:40
你想建设一个能承受500万PV/每天的网站吗？
500万PV是什么概念？我的服务器每秒要处理多少个请求？
PV是什么？
PV是page view的简写。PV是指页面刷新的次数，每一次页面访问，就算做一次pv流量。
计算模型：
每台服务器每秒处理请求的数量=（（80%*总PV量）/（24小时*60分*60秒*40%））/服务器数量
其中关键的参数是80%、40%。表示一天中有80%的请求发生在40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用）。
（（80%*500万）/（24小时*60分*60秒*40%））/1 = 1157个请求/秒
（（80%*100万）/（24小时*60分*60秒*40%））/1 = 231个请求/秒
结论：
现在我们在做压力测试时，就有了标准，如果你的服务器一秒能处理1157个请求，就可以承受500万PV/每天。这里不关心是请求的是静态的html，还是动态的jsp。
如果你的服务器一秒能处理231个请求，就可以承受100万PV/每天.
说明：这里说明每秒N个请求，更像是TPS。而不是请求一个html页面而附带请求的css,js,图片。因为我关心的是应用程序处理业务的能力。
---------------------------------------------------------------------------------------
基本概念：
Throughput（吞吐量）：按照常规理解网络吞吐量表示在单位时间内通过网卡数据量之和，其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量。
并发用户数：是同时执行操作的用户
响应时间：对请求作出响应所需要的时间
---------------------------------------------------------------------------------------
JMeter测试参数说明：
Label：每一个测试单元的名字。
#Samples：表示一个测试单元一共发出了多少个请求。
Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间。，不重要。
Median：中位数，也就是 50％ 用户的响应时间，如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。重要。
90% Line：90％ 用户的响应时间，如果把响应时间从小到大顺序排序，那么90％的请求的响应时间在这个范围之内。重要。
Min：最小响应时间，不重要。
Max：最大响应时间，出现几率只不过是千分之一甚至万分之一，不重要。
Error%：本次测试中出现错误的请求的数量
Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数
KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec
---------------------------------------------------------------------------------------
loadrunner测试参数说明：
响应时间： 取90%值，如果把响应时间从小到大顺序排序，那么90％的请求的响应时间在这个范围之内。重要。
每秒点击数 ：hits per Second,每秒钟向服务器提交请求的数量。
TPS： Transaction per Second ，每秒事务数，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程
Throughput（吞吐量）： Loadrunner记录的Throughput是接收到服务器返回的所有字节数之和，与本地发出的字节数无关。
Throughput/Sec： 每秒的吞吐量。
对于BS架构的一般分析 响应时间、点击率、吞吐量、TPS（每秒事务数）。
对于CS架构的一般分析 TPS（每秒事务数）
---------------------------------------------------------------------------------------
Apache ab测试参数说明：
RPS： Request per Second,每秒处理的请求数
详见：
http://blog.chinaunix.net/u3/108043/showart_2260477.html
---------------------------------------------------------------------------------------
测试配置如下图： 其实jmeter还是很弱的，我打开"集合点（synchronizing Timer）","察看结果树"，"用表格查看结果"中的任何一个都会导致性能下降和小部分请求的响应出错（可能是线程数太多了），所以禁用了。只启用了cookie管理器。
---------------------------------------------------------------------------------------
Tomcat6.0 配置文件的说明 ，做测试之前是要整清楚的。
默认的Server.xml中如下
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />
enableLookups
是否允许DNS查询，当web应用程序要通过域名服务器查找机器名转换为IP地址时。会使用DNS查询，需要占用网络，延长较长
maxThreads
Tomcat可创建的最大的线程数，每一个请求须要一个线程来处理，原来的150太小了，我们测试时并发会超过他的。
acceptCount
指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，就是被排队的请求数，超过这个数的请求将拒绝连接。
connnectionTimeout
网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为20000毫秒。
minSpareThreads
Tomcat初始化时创建的线程数
maxSpareThreads
一旦创建的线程中空闲线程超过这个值，Tomcat就会关闭不再需要的socket线程。
注意：maxThreads 设置为500，也就是最多有500个线程，为下一步的压力测试做好准备。
---------------------------------------------------------------------------------------
测试环境说明：
服务器： 4G内存，至强3.0 （4核超线程）CPU，windows 2003
测试机：笔记本 2G内存，p8600 CPU，windows XP
网络：100Mb局域网
测试软件：
Jmeter 2.3.4 分配了512M内存
tomcat 6 默认内存大小
---------------------------------------------------------------------------------------
测试时服务器CPU使用率 10%
测试时测试机CPU使用率 100%(测试机不行啊)
每次测试CPU都这样，就统一写这里了。
测试1：2213个请求/秒
100并发，循环100次，共10000个请求，请求一个大小3.34KB的jsp页面。
测试2：1889个请求/秒
100并发，循环100次，共10000个请求，请求一个servlet总控制器，验证权限后，new一个Action,再转发到一个大小3.34KB的jsp页面。
测试3：2607个请求/秒
100并发，循环100次，共10000个请求，请求一个3.2KB的html页面。
测试4： 833个请求/秒
100并发，循环100次，共10000个请求，请求一个13.4KB的html页面。与上面比是只是文件大了一些，性能就降了不少！！
测试5： spring 2012个请求/秒
100并发，循环100次，共10000个请求，请求一个spring3 MVC的action,再转发到一个0.8K的JSP，其内容是简单的html
测试6： spring 1800-1924个请求/秒
100并发，循环100次，共10000个请求，请求一个spring3 MVC的action,两个参数类型转换为int、Date，再new 一个List，再转发到一个1.3K的JSP,用JSTL标签显示List中的内容。
JSTL标签内容是如下，看来JSTL标签性能还是不错的。 无记录！ 从 1 开始的迭代计数 从 0 开始的迭代计数 产品名称 ${s.count} ${s.index} ${item}
测试7： 图片 1997个请求/秒
100并发，循环100次，共10000个请求. 因为我使用了spring3 MVC，拦截/，所以图片不能访问，所以添加了：
走默认的servlet，来访问2.5K的图片
测试8： 图片 1967个请求/秒
100并发，循环100次，共10000个请求，因为我使用了spring3 MVC，拦截/，所以图片不能访问，所以添加了：
来访问2.5K的图片，会走spring的可匹配的一个拦截器。
测试9：Struts2的测试
100并发，循环1次，没有循环100次，因为strtus2在这次测试中响应太慢了，我等不起了，所以单个url的测试样本从10000降到了100.一共11个url，共1100个样本。
"spring" 使用的就是前面“测试5”的URL，放在这里是为了与strtus2对比的。
"html" 使用的就是前面“测试3”的URL，放在这里是为了与strtus2对比的。
"struts2-1" 使用的是官方自带的示例项目，名称是struts2-blank-2.1.8.1.war
"struts2-2" 使用的是官方自带的示例项目，名称是struts2-showcase-2.1.8.1.war，我在其中随便选了一个action来做测试
"struts2-3" 同上
"struts2-4" 同上
"struts2-5" 同上
"struts2-6" 同上
"struts2-7" 同上
"struts2-8" 同上
"struts2-9" 同上
太忙了，没有时间对Struts2做优化，使用的都是官方带的示例，Struts2的测试结果不理想，放在这里做一个参考。“struts2-1”是struts2中测试成绩最好的，但也不理想。
测试10：Struts2的测试。
上一个测试结果太离谱了，第二天，想了想又重新测试了下，使用的还是struts2官方提供的struts2-blank-2.1.8.1.war示例。访问下面的action,action内容简单就是转发到一个JSP。
下图是示例默认的action，我没有修改：
要说一说转发到的jsp,其中有struts2标签
我把jsp改了，删除了所有struts2标签，只输出一行文件
天啊，性能超出我的想像，太好了。看来是struts2标签拖了后腿。
我把jsp改了，换了其它的struts2标签
标签是：
看来struts2的标签性能太差了。
Struts2由于采用了 值栈、OGNL表达式、struts2标签库等，会导致性能下降。如果避免或减少使用这些，性能还是很好了。
Struts2的
注：以上测试都没有数据库，也没有业务，action中，jsp中内容很简单。
---------------------------------------------------------------------------------------
其它测试文章：
http://zhaoshg.iteye.com/blog/356231
MVC框架性能比较
spring3mvc与struts2比较
附：
几种标签和框架组合解析数据时候的 性能测试对比
一、 数据
数据通过查询日志表得到数据，共 1302 条数据，将查询出的数据放入一个静态 List 中，保证每次请求的数据相同。
测试页面的元素相同，只是在取数据方式上不同。
二、 测试目标
1、 在 JSP 页面使用 struts2 标签的性能；
2、 在 JSP 页面使用 JSTL 标签的性能；
3、 在 Freemarker 页面使用 struts2 标签的性能；
4、 在 Freemarker 页面使用 JSTL 标签的性能；
5、 在 Freemarker 页面使用其本身的数据加载方式的性能。
三、 加载耗时对比
时间： ms 注：每一次对比都是在同一时间段按同一顺序依次执行下列几种方式
| struts2 | JSTL （ C ） | Freemarker-struts2 | Freemarker-C | Freemarker |
第一次 | 306 | 58 | 1618 |
| 41 |
第二次 | 202 | 52 | 1643 |
| 39 |
第三次 | 211 | 58 | 2047 |
| 36 |
第四次 | 196 | 49 | 1621 |
| 28 |
第五次 | 218 | 52 | 1607 |
| 40 |
第六次 | 303 | 331 | 1857 |
| 45 |
第七次 | 210 | 50 | 1671 |
| 33 |
第八次 | 311 | 51 | 1699 |
| 47 |
第九次 | 462 | 55 | 2180 |
| 37 |
第十次 | 218 | 46 | 1721 |
| 42 |
平均值 | 263.7 | 80.2 | 1766.4 |
| 38.8 |
去掉最高和最低 | 223.75 | 53.125 | 1547.125 |
| 39.125 |
