平均相应时间

也称为系统响应时间，它一般指在指定数量的VU情况下，每笔交易从mouse 的click到IE的数据刷新与展示之间的间隔，比如说：250个VU下每笔交易的响应时间不超过2秒。

当然，响应时间也不能一概而论，对于实时交易如果银行柜台操作、超市收银员（邪恶的笑。。。）的操作、证交所交易员的操作来说这些操作的响应时间当然是越快越好，而对于一些企业级的如：

与银行T+1交易间的数据跑批、延时交易、T+1报表等，你要求它在2秒内响应，它也做不到啊。就好比你有个1MB的带宽，你传的东西是超过4MB，你要它在2秒内跑完理论速度也做不到啊，对吧，所以有些报表或者数据，光前面传输时间就不止两秒了。。。一口咬死说我所有的交易平均相应时间要2秒，真的是不科学的！

2.4 合理的性能测试

VU数量的增加

一个合理的性能测试除了需要合理的计算VU的数量、合理的设置系统平均响应时间外还需要合理的在测试时去规划发起VU的时间，比如说，我看到有人喜欢这样做压力测试。

第一秒时间，500个并发用户全部发起了。。。结果导致系统没多久就崩了，然后说系统没有满足设计要求。

为什么说上述这样的做法是不对的？我们说不是完全不对，只能说这样的测试已经超过了500个VU的并发的设计指标了。

合理的并发应该是如下这样的：

有25-50个VU开始起交易了，然后过一段时间又有25-50个用户，过一段时间又增加一些VU，当所有的设计VU都发起交易了，此时，再让压力测试跑一段时间比如说：24*7是比较合理的。所以VU数量不是一上手就500个在一秒内发起的，VU数量的增加应该如下面这张趋势图：

这是一个阶梯状的梯型图，可以看到VU的发起是逐渐逐渐增多的，以下两种情况如果发生需要检查你的系统是否在原有设置上存在问题：

• VU数量上升阶段时崩溃

有时仅仅在VU数量上升阶段，系统就会了现各种各样的错误，甚至有崩溃者，这时就有重新考虑你的系统是否有设置不合理的地方了。

• VU全部发起后没多久系统崩溃

VU在达到最高值时即所有的VU都已经发起了，此时它是以一条直的水平线随着系统运行而向前延伸着的，但过不了多久，比如说：运行24*7小时，运行了没一、两天，系统崩溃了，也需要做检查。

所以，理想的性能测试应该是VU数量上升到最终VU从发起开始到最后所有VU把交易做完后，VU数量落回零为止。

吐吞量的变化

从2.3节我们可以知道，吞吐量是随着压力/性能测试的时间而逐渐增大的，因此你的吞吐量指示应该如下图所示：

肯定是这样，你的吞吐量因该是积累的，如果你的吞吐量在上升了一段时间后突然下落，而此时你的性能测试还在跑着，如下图所示：

那么，此时代表什么事情发生了？你可以查一下你的loaderrunner或者jmeter里对于这段吞吐量回落期间的交易的response的状态进行查看，你将会发现大量的error已经产生，因为产生了error，所以你的交易其实已经出错了，因此每次运行的数据量越来越小，这也就意味着你的压力测试没有过关，系统被你压崩了！

平均响应时间

平均响应时间如VU的数量增加趋势图一样，一定是一开始响应时间最短，然后一点点增高，当增高到一定的程度后，即所有的VU都发起交易时，你的响应时间应该维持在一个水平值，然后随着VU将交易都一笔笔做完后，这个响应时间就会落下来，这段时间内的平均值就是你的系统平均响应时间。看看它，有没有符合设计标准？

内存监控

我们就来说AppServer，我们这边用的是Tomcat即SUN的JVM的内存变化，我们就用两张图例来讲解吧：

理想状态情况下的JVM内存使用趋势：

这是一个波浪型的（或者也可以说是锯齿型的）趋势图，随着VU数量的一点点增加，我们的内存使用数会不断的增加，但是JVM的垃圾回收是自动回收机制的，因此如果你的JVM如上述样的趋势，内存上涨一段时间，随即会一点点下落，然后再上涨一点，涨到快到头了又开始下落，直到最后你的VU数量全部下降下来时，你的JVM的内存使用也会一点点的下降。

非理想状态情况下的JVM内存使用趋势：

嘿嘿嘿，看到了吗？你的JVM随着VU 数量的上升，而直线上升，然后到了一定的点后，即到了java –Xmx后的那个值后，突然直线回落，而此时你的交易还在进行，压力测试也还在进行，可是内存突然回落了。。。因为你的JVM已经crash了，即OUT OF MEMORY鸟。

CPU Load

我们来看一份测试人员提交上来CPU得用率的报告：

同时平均响应时间好慢啊。

拿过来看了一下代码与设计。。。Struts+Spring+JDBC的一个框架，没啥花头的，再仔细一看Service层。

大量的复杂业务逻辑甚至报表的产生全部用的是javaobject如:List, Hashmap等操作，甚至还有在Service层进行排序、复杂查询等操作。

一看DB层的CPU利用率才6%，将一部分最复杂的业务拿出去做成Store Procedure（存储过程后），再重新运行压力测试。

同时平均响应时间比原来快了15-16倍。

为什么？？

看看第一份报告，我们当时还查看了数据库服务器的配置，和APPServer的配置是一个级别的，而利用率才6%。。。

数据库，至所以是大型的商用的关系型数据库，你只拿它做一个存储介质，你这不是浪费吗？人家里面设置的这个StoreProcedure的处理能力，索引效率，数据分块等功能都没有去利用，而用你的代码去实现那么多复杂业务比如说多表关联、嵌套等操作，用必要吗？那要数据库干什么用呢？

是啊，我承认，原有这样的代码，跨平台能力强一点，可付出的代价是什么呢？

用户在乎你所谓的跨平台的理论还是在乎的是你系统的效率？一个系统定好了用DB2或者是SQL SERVER，你觉得过一年它会换成ORACLE或者MYSQL吗？如果1年一换，那你做的系统也只能让用户勉强使用一年，我劝你还是不要去做了。在中国，有人统计过5年左右会有一次系统的更换，而一些银行、保险、金融行业的系统一旦采用了哪个数据库，除非这个系统彻底出了问题，负责是不会轻意换数据库的，因此不要拿所谓的纯JAVA代码或者说我用的是Hibernate,ejb实现可以跨数据库这套来说事，效率低下的系统可以否定你所做的一切，一切！

三、Apache服务器的优化

上面两节，讲了大量的理论与实际工作中碰到的相关案例，现在就来讲一下在我们第一天和第二天中的ApacheHttp Server + Tomcat这样的架构，怎么来做优化吧。

3.1 Linux/UnixLinux系统下Apache 并发数的优化