5.1.3  一个视频网站例子

项目背景信息

近两年，随着网络的发展，视频网站如雨后春笋般出现。尤其一些热门的视频网站，拥有巨大的用户群体。如一些知名电视台的宽频网站，在社会发生热点新闻期间的并发用户访问数量会达到百万级以上。巨大的并发访问量对系统的性能提出了非常高的要求。

本案例探讨的是一个已经上线的视频网站遇到的性能问题，该系统的设计目标是每天150万的PV（页面浏览）量。在上线后，由于用户并发量较大，CPU的利用率经常高居100％，导致Oracle数据库发生停止服务的现象。数据库不工作，网站运营人员就无法维护系统，甚至导致终端用户不能正常访问网站。显然，这类问题是不能容忍的。

在探讨性能测试工作之前，先简要介绍这个系统的体系结构，其功能点将在后面的内容中陆续介绍。整个系统由下面两块组成：

视频发布系统：该系统是一个成型的产品，主要功能是建立一个运营平台，把视频发布到系统中，并为门户提供接口。本系统已经有多家成功应用的案例。

网站门户：对视频发布系统进行二次开发后实现的一个应用。借助视频发布平台提供的接口，门户实现了和视频发布系统所维护的运营平台之间的信息交互。网站的用户主要通过门户来欣赏视频。

下面开始探讨如何测试系统的性能问题。

实验室的测试执行与结果分析

对本系统而言，由于已经发现了问题，所以性能测试的目标非常明确，就是要找出导致数据库停止服务的原因。而分析这类问题时，很容易想到两个常见的原因：程序算法上的缺陷或数据库配置不正确。算法上的缺陷会导致CPU资源过度消耗，而配置不正确也会引起数据库系统运行异常。因此，性能测试设计和实施将围绕这两个目标来进行。

下面详细介绍实验室的性能测试过程。

1. 测试用例设计

由于问题出在数据库上，因此测试用例应该针对数据库来进行。数据库的测试通常会分为下面三个步骤：

首先，把数据库的操作分为Insert 、Update、Delete、Select四种，分别隔离进行测试，并定位哪种操作容易引起问题；

其次，把用户的日常操作模拟出来，也就是把用户对数据库的操作组合起来进行测试；

最后，做一些疲劳强度或大数据量的压力测试，以使问题快速重现。

确定了整体方案后，接下来就要确定测试过程需要模拟哪些用户操作。分析整个系统的结构，可以看出视频发布系统出问题的可能性不大，因为这是一个成型的产品。因此，问题更可能会出现在网站的门户或门户与视频发布系统的接口上。

经过进一步的分析，了解到网站门户用户访问量主要有三个页面：

视频首页：视频首页是导航页面，主要操作有查找热点视频或自己关注的视频、进入二级分类页面、进入播放页面等。

收费播放页面：付费用户播放视频时进入的页面。

免费播放页面：用户播放免费视频时进入的页面。

这三个页面应该是重点测试的对象，用户日常操作组合测试、疲劳强度与大数据量测试都应该针对它们进行。确定了测试内容后，就可以开始性能测试的实施了。

2. 测试实施过程

不难看出，实验室测试是一个紧急的性能测试任务，因此没有时间进行正规的规划与设计，更多的是一种应变测试。为了保证系统的“正常”运行，环境设在了实验室里，配置如表5-1所示。

表5-1  测试硬件配置

	硬件配置	软件配置
数据库服务器	服务器：两台Dell 2850 CPU：Xeon 3.0GB ´ 2 内存：2GB	操作系统：企业版Windows 2003（SP1） 数 据 库：Oracle10g
应用服务器		操作系统：企业版Windows 2003（SP1） Web Server：IIS6.0

作者在《Web性能测试实战》一书中曾经讨论过，由于硬件环境的差异，实验室里的调优只能作为上线后的参考。实验室测试比较适合找出由软件自身缺陷引起的性能问题，较容易发现一些算法方面的缺陷。

常规并发用户测试

由于实验室与用户现场的硬件环境差别较大，因此应该先在实验室中进行“预测试”，看看系统在实验室中的性能表现，为后面的测试提供参考。在本案例中，先选择50个并发用户来观察系统的性能表现，压力持续时间为30分钟。

经过测试后，利用Analysis进行分析，得到了如图5-10的测试结果摘要。从图中可以看出：视频首页（Index页面）不能访问，收费播放页面（Play访问）的平均访问时间为181.834秒。

图5-10  50个并发用户的预测试结果

由此不难得出结论：这是一个过于缓慢的系统！需要进行调整后才能正常开展测试工作。

通常情况下，对这类系统进行调整首先应从系统的参数配置或硬件配置入手，然后分析软件自身的原因。这样做的原因是参数配置不正确的错误很容易纠正，也是常见的性能问题，而分析软件本身则是后面测试工作的主要内容。因此，在查看了Oracle的服务器配置后，立刻发现了一个参数配置问题：Oracle数据库的运行模式是“专有服务器模式”！而“共享服务器模式”才是更适合大规模并发的模式。

关于Oracle服务器的运行模式 在专用服务器模式下，用户连接所需要的全部资源在PGA中进行分配。该内存区为指定私有连接，其他进程不能访问。专用连接采用一对一的连接方式，能很快地响应用户的请求。但是，当用户连接过多时，由于要对每一个用户连接分配资源，因此，连接个数受硬件的限制比较大。为了克服这种情况，Oracle提供了共享服务器运行模式，即用一个服务器的进程响应多个用户连接。只要实例一启动，就分配指定数量的服务器进程，所有用户的连接以排队的方式由分配器指定给服务器进程，其他的进程排队等待。只要用户的请求执行完，就会马上断开连接，分配器会把空闲的服务器进程分配给其他排队的进程。

因此，首先要把Oracle的运行模式调整为“共享服务器模式”再进行测试。

分析“Summary”的意义 从上面的内容可以看出，“Summary”的分析结果决定了是否继续进行后面的工作。在本案例中，通过“Summary”看出系统性能非常令人不满意，因此没有必要进行深入分析。正确的做法是立刻采取调优措施，否则测试工作将无法正常开展下去。

独立场景测试  下面是Oracle调整为“共享服务器模式”后的测试实施过程。为了更好地对问题定位，测试只针对播放页面来进行。图5-11是800个用户并发、压力持续30分钟的测试结果综述。

从图5-11中可以看出，“Action”事务即打开播放页面的平均时间是1.354秒，这是非常好的结果。但是应该注意到：半小时内有超过17万个播放页面不能正常打开，同时计算出为“打开播放页面”事务的通过率为82%。82%的事务通过率标志着后续的性能测试任务十分艰巨，而半小时内超过17万个播放页面不能正常打开，是任何视频网站都不能接受的。

为了让问题更好地暴露出来，我们又进行了一次更长时间的场景测试：压力持续时间增加到三倍，即1.5个小时；并发用户增加到了900个。测试结果如图5-12所示。

与图5-11的测试结果相比，得到如下结论：“打开播放页面”事务的平均响应时间稍稍变大，这是用户数量变大的正常反应；事务通过率85%与82%相比没有太大变化。稍稍提高的通过率很可能是由于测试时间较长、打开的部分页面存在于服务器缓存中造成的。

图5-11  共享模式下800个用户的并发测试结果

图5-12  共享模式下900个用户的并发测试结果

这时，打开Oralce的管理工具，借助Oralce提供的工具进行分析。结果发现了五个问题！如图5-13所示。

图5-13  数据库分析的结果

打开图5-13中的“发现SQL语句消耗了大量数据库时间”链接进行查看，发现Oracle找出了三个SQL语句的问题，而这三个语句恰恰是播放页面频繁使用的语句！终于找到了程序本身的一个原因：SQL语句消耗了大量的数据库时间，其他问题极有可能是语句不合理引起的。主要推理如下：当一些反复执行的SQL语句效率过低时，首先会造成高速缓存不够用，随之引起较大的I/O；而频繁的I/O势必会消耗大量的CPU。因此整个系统的瓶颈极有可能是这三个语句引起的。

测试过程中棘手的性能问题 这两次测试结果还有一个奇怪的现象：一方面事务响应时间较快，另一方面却有大量的事务没有响应。仅根据目前的测试结果还看不出直接原因。但这也很可能是前面的三个SQL语句引起的：因为这种现象很像用户直接收到不能访问的通知，所以不再等待服务器的结果反馈，在客户端的表现就是页面无法打开。 这种现象很有可能是耗资源的SQL语句瞬间霸占了全部CPU资源，导致数据库拒绝服务。当调整了SQL语句再次进行测试时，这种现象消失，证明推理是正确的。

再借助Analysis打开图5-14的“事务平均响应时间图”和图5-15的“建立第一个缓冲的时间分解图”，可以得出以下结论：

（1）事务平均响应时间稳定，说明本次测试的性能问题主要在程序自身。如果是服务器存在问题，则长时间的压力测试会导致响应时间越来越长；

（2）“建立第一个缓冲的时间”主要消耗在服务器上，说明对用户请求的处理方式不合理。

图5-14和图5-15进一步证明了SQL语句可能就是造成系统瓶颈的根本原因。

图5-14  事务平均响应时间图

图5-15  建立第一个缓冲的时间分解图

因此，下一步应该先对SQL语句进行优化，然后对系统进行测试。

SQL语句调整后的测试  开发人员优化了SQL语句后，并对900个用户进行并发、持续1.5小时的压力测试，测试结果如图5-16所示。从图中可以看出，调整后系统的性能非常稳定，所有的用户均可以成功打开“视频播放页面”。

图5-16  SQL语句调整后的测试

再借助Analysis打开图5-17所示的事务平均响应时间图，可以看到整个测试过程“打开播放页面”的平均响应时间成平滑水平线，系统的性能非常稳定。

由此可以得出结论：调整SQL语句的策略是正确的。

图5-17  调整后的事务平均响应时间图

与图5-11和图5-12的测试结果相比，有个细节在分析的时候应该注意到，那就是事务评价响应时间变长了！前面两次测试结果的事务平均响应时间是1秒，而本次则是39秒。那么，哪次的测试结果更合理呢？

根据常理，本次测试用的是普通的PC服务器，900个并发用户用1秒的响应时间显然不合理， 39秒才符合实际情况。1秒的事务平均响应时间只是一种假像，是系统存在性能问题造成的。对于“播放页面”的性能，在图5-16中有稳定表现，可以认为测试过关！

到目前为止，本次性能测试的思路是正确的，可以推广到其他功能点的独立或组合性能测试中。

3. 性能调优方案

最后，对整个上线系统提出了以下调优方案：

系统配置方面

（1）把Oracle的运行模式调成“共享服务器模式”；

（2）增加了分配给Oracle的内存：把内存调整成系统内存的55%；

（3）增加共享池（SHARED_POOL）和缓冲区高速缓存（DB_CACHE）的大小；

（4）对数据库表和查询相关的字段建立索引；

应用程序方面

（1）用优化后的程序来替换原有程序；

（2）采用页面缓存技术来提高用户访问速度，同时减缓对数据库的压力；

线上的性能测试验证

按照调优方案对线上系统进行调整后，接下来的工作就是和客户一起验证系统的综合性能表现。线上测试与实验室测试不同，不能影响用户的正常使用——不但不能产生垃圾数据，更不能把服务器压垮。

在前面的项目背景中，提到过本系统的设计目标是满足每天150万的PV（页面浏览量），因此，线上测试主要是为了评估服务器能够处理的浏览量。同时，为了保证服务器的稳定运行，在真实线上环境只模拟了500个并发用户。

下面是对线上系统首页的测试结果摘要，主要测试了动态页面无缓存、静态页面缓存方式两种情况：

1. 页面无缓存、500用户并发

测试场景持续执行时间：6分钟

运行的最大用户数： 1000个

测试内容：打开任意视频进行播放

事务平均响应时间如图5-18所示。

图5-18  事务平均响应时间

事务响应时间的详细情况如表5-2所示。

表5-2  事务响应时间（秒）

最小值	平均值	最大值
0.622	6.247	12.338

CPU利用率如图5-19所示。

图5-19  CPU利用率

其中服务器CPU利用率（％）的详细情况如表5-3所示。

表5-3  服务器CPU利用率

	最小值	平均值	最大值
Oracle服务器	0.0	82.723	95.703
Web服务器	4.688	67.543	95.833

每秒播放页面下载数如图5-20所示。

图5-20  每秒页面下载数

每秒播放页面下载数的详细表情况如表5-4所示。

表5-4

最小值	平均值	最大值
0.0	67.126	92.25

本次测试结论如下：

Oracle服务器CPU的平均利用率为82.723％，说明数据库系统稳定运行。Web服务器的CPU平均利用率是67.543％。如果按一天8小时计算，一台服务器每天的PV均值为：67.126*3600*8≈193万个，足可以支撑150万个PV。

2. 采用静态页面缓存方式、500用户并发

测试场景持续执行时间：6分钟

运行的最大用户数：1000个

测试内容：打开任意视频进行播放

测试过程中的事务平均响应时间如图5-21所示。

图5-21  事务平均响应时间

事务平均响应时间的详细情况如表5-5所示。

表5-5

测试过程中CPU利用率如图5-22所示：

图5-22  CPU利用率

其中服务器CPU利用率（％）的详细情况如表5-6所示。

表5-6  CPU利用率（％）测试结果数据

	最小值	平均值	最大值
Oracle服务器	0.0	8.267	15.445
Web服务器	3.125	67.327	89.119

测试过程中每秒播放页面下载数如图5-23所示。

图5-23  每秒页面下载数

每秒播放页面下载数的详细情况如表5-7所示。

表5-7  播放页面下载结果数据

最小值	平均值	最大值
24.375	69.043	96.125

本次测试结论如下：

Oracle服务器CPU的平均利用率非常低，为8.267％，这说明静态页面缓存技术大大节省了对数据库的资源消耗，系统更加稳定运行。Web服务器的CPU平均利用率是67.323％。如果按一天8小时计算，一台服务器每天的PV均值为：69.043*3600*8≈199万个，足可以支撑150万个PV。

在满足系统性能测试目标的前提下，Oracle数据库CPU的利用率不足10％，标志着本次性能测试工作圆满完成。

案例总结

通过本项目的性能分析，相信读者更加体会到性能分析是一个相当复杂的过程，仅靠Analysis是远远不够的。在实际工作中，往往会借助各种系统工具以及各方面的综合知识找出系统的瓶颈。例如在本项目中，Oracle自带的管理工具起了至关重要的作用，本案例恰恰是借助它发现了引起系统瓶颈的SQL语句，借助这个突破口逐步解决了其他性能问题。

当进行性能分析与调优时，应该先从容易的地方入手。这样做的原因是可以先排除常见的、容易引起瓶颈的问题，避免各种因素混杂在一起不容易对问题进行定位。例如，本案例就是先从Oracle参数配置入手，逐步深入到应用程序内部。

在实际项目中，还应该要细心地查看Analysis的各种分析报表，不能让任何一个性能问题从“眼皮底下”溜掉。在“抓住了”系统存在问题后，就可以深入地分析下去。