Web 服务器通用性能测试系统的设计与实现

2010-10-29 作者：武海平蒋东兴程志锐康晓宁来源：网络

摘要 ：性能测试系统能够在应用系统遭受实际压力之前测算出系统能够承受的负荷，作者设计并实现了一个 Web 服务器的性能测试系统，该系统能够模拟真实的用户行为对各种 Web 服务器进行大用户量访问测试，为 Web 服务器的性能评估提供数据依据。本文介绍了此系统的设计思路和关键技术，并介绍了该系统在清华大学选课系统测试中的实际应用情况。

关键字 ： Web 服务器性能测试

中图分类号 ： TP302.1

Design and Implementation of Performance Measure System of Web Server

Wu Haiping Jiang Dongxing Qili Cheng Zhirui Kang Xiaoning

( Computer & Information Center of Tsinghua University , Beijing , 100084)

Abstract : This paper presents a performance measure system of web server. This system can imitate a large quantity of real users to visit a web server. Administrator can evaluate how many users this web server can accommodate according to the result of measure system.

Keywords : Web Server Performance Measure

1 引言

随着 Internet/Intranet 技术的迅速发展，许多公司、企业和网站建立了不少基于 Web 的应用系统。一般地，在设计开发 Web 应用系统的时候，很难模拟出大量用户同时访问系统的实际情况，使得 Web 应用系统投入使用以后，当遇到访问高峰时，容易发生服务器响应速度变慢甚至服务中断。为了避免这种情况，需要一种能够真实模拟大量用户访问 Web 应用系统的工具程序，当 Web 应用在设计开发阶段时，使用这一工具对 Web 应用进行压力性能测试，及时发现 Web 应用系统的服务瓶颈，以便采取相应的措施。为此，我们开发了 Web 服务器性能测试系统，这个系统不仅能够测试静态 HTML 页面的响应时间，而且能够模拟真实运行情况测试动态网页（包括 ASP 、 PHP 、 JSP 等）的响应时间，为服务器的性能优化和调整提供数据依据。

2 HTTP 协议简介

目前的 Web 应用系统，无论是显示静态 HTML 页面，还是通过 ASP 、 PHP 或者 CGI 等技术显示动态页面，都是通过 HTTP 协议 [1][2] 和用户进行交互的。 HTTP 协议是应用层协议，用于发布、编写超文本信息。在 HTTP 协议中，用户通过标定 URL （ Uniform Resource Locators ）来确定访问的页面。如果用户需要访问动态页面，也通过 URL 来传递参数。 URL 格式如下：

http_URL = "http: //" host [ ":" port ] [ abs_path [ "?" query ]]

其中，“ http:// ”表明网络协议名称，“ host ”表示要访问的主机名称，“ port ”表示访问的端口，“ abs_path ”表示要访问的页面的路径，“ ? ”和后面的 query 表示要传递的参数。用户只是访问静态的 HTML 页面时， URL 中没有“ ? ”和后面的 query 字符串，如果用户访问的是动态页面，那么 URL 中的“ ? ”和后面的 query 字符串会传递给下一个动态页面。一般 query 字符串中包含着用户的查询条件。

query 字符串中的参数传递给服务器有两种方法，分别是“ POST ”方法和“ GET ”方法。“ GET ”方法通过环境变量读取用户传递的 query 字符串参数，“ POST ”方法读标准输入 (STDIN) 获得表单中输入的各项内容，通过写标准输出 (STDOUT) 回传客户端的信息。在 HTML 表单中，一般使用 POST 方法传递参数数据。

3 系统设计

一般的 Web 性能测试工具，例如 Apache 自带的测试小程序 ab ，只能测试静态页面的响应时间。为了能够模拟大量用户同时访问 Web 动态页面的情况，必须要解决下面两个问题： ① 测试工具需要模拟出大量用户同时访问 Web 的情况； ② 测试工具需要模拟出单个用户访问 Web 时个性化的请求参数。本性能测试系统主要由两部分构成：性能测试数据文件和性能测试程序。其中，性能测试数据文件包含着用户访问 Web 的 URL 请求格式和大量用户访问系统的请求数据（例如用户名和密码等）。实际测试中，性能测试程序将开设多个进程模拟大量用户对 Web 的访问，每个进程从性能测试数据文件中随机地读出一组访问数据，然后发起对 Web 服务器的访问，等待 Web 服务器应答。测试结束后，性能测试程序将给出对于所有请求的平均系统响应时间。由此，本性能测试工具能够真实地模拟大量用户同时访问 Web 的情况。

在实际运行的 Web 应用系统中，用户访问动态页面时传递的 query 字符串中的参数是互不相同的。为了逼真地模拟实际情况，性能测试系统应该在一段特定的时间内，对待测页面同时发送多个请求，每个请求的 query 参数互不相同，发送同时开始计时，直到收到系统的响应，计时停止，最后对所有请求的响应时间进行分析，就可以得到系统性能的定量估计。系统结构如图 1 所示：

图 1 系统结构示意图

实际系统由四部分组成：

● 模板文件

● 数据文件

● 性能测试程序

● 结果处理程序

模板文件为纯文本文件，包含单个用户访问 Web 发送的 URL ，每行格式如下：

GET(POST) http://host:port/path/filename?xxx=@1@&@2@

其中 GET 或者 POST 表示参数传递的方式， query 字符串中的 @ 是本系统特设字符，表示 @ 及其后面的数字需要被数据文件中对应的参数数据所取代。两个 @ 之间为参数序号，只能为数字，在整个模板文件中相同的参数序号代表相同的参数。

数据文件是用户访问动态页面时传递的 query 参数集合，为纯文本文件，参数数据与模板文件中 @ 号及其后面的数字相对应，之间用空格隔开，每组一行。

测试 Web 应用系统时，性能测试程序将开设 c 个进程，每个进程可以串行地开设 n 个会话，每个会话模拟一个真实用户，按照模板文件中提供的访问 Web 系统的格式，从数据文件中读取一组 query 参数，然后对 Web 系统发起请求；与此同时，程序开始计时，直到收到系统的响应，计时停止，系统统计接收的字节数，将结果写入结果文件，本次会话结束，这个进程开始一个新的会话，如此循环 n 次。测试结束后，结果处理程序对结果文件中每个请求的响应时间进行统计分析，给出系统的综合性能评估。

从上面的分析可以看出，本系统发送请求的并发度是 c ，即在测试的时间段内，对 Web 应用系统同时发送的请求有 c 个；本系统发送请求的串行度为 n ，一共可以模拟 c*n 个用户对系统的访问。

性能测试程序流程如图 2 所示：

图 2 主程序流程

如图 2 所示，性能测试程序 fork 出 c 个进程，每个进程都开设一个 Socket ，通过 Socket 向 Web 服务器发送请求。为了使测试程序能够快速地向服务器发送请求，程序一开始就将数据文件中所有数据读入内存，数据使用一个二维数组存放。

模板文件中的请求格式在程序开始时读入模板数据结构中，模板数据结构定义如下：

struct _tag_Template {

int count; // 本模板中共包含的请求个数

char *method; // 各请求发送的方法 , 0 = GET , 1 = POST,

char **host; // 各请求发送的目的主机名

int *port; // 各请求发送的目的主机端口号

char **path; // 各请求要求的路径文件名

char **paramstr; // 各请求包含的参数

}TEMPLATE;

测试程序运行结束后，生成的结果文件包含着 Web 服务器对每个请求的响应时间，还包含每个请求返回的字节数。结果文件由结果处理程序处理，计算出 Web 服务器对所有请求的平均响应时间。

4 系统应用

我们使用本性能测试系统，对清华大学学生选课系统进行了性能测试 [3] 。清华大学学生选课系统 1997 年开发投入使用，系统的应用服务器是 Oracle Application Server 4.0 ，使用 PL/SQL 编写。使用本系统进行测试时，应用服务器选用的是 SUN Enterprise Server 3000 ， 2 个 CPU ， 1G 内存，客户端使用了 8 台 Linux 小型服务器，每台小型服务器最多可以开设 300 个进程，这样系统可以模拟到 2400 个学生同时选课的实际情况。我们对 100 、 200 、 300 、 400 、 500 、 600 、 700 、 800 个用户同时访问选课系统时系统平均响应时间进行了统计。统计结果如图 3 所示：

图 3 对 Oracle Application Server 4.0 的性能测试

从图 3 可以看出，当并发访问人数超过 600 时，系统的平均响应时间已经接近到 10 秒钟左右，这时用户会感觉到系统变慢。由此，只要估计出系统高峰时并发人数，就可以计算出需要多少台 Web 服务器。

在进行性能测试之前，清华大学选课系统使用的 OAS 配置结构采用一台 OAS ， OAS 安装在一台 SUN3000 服务器上，数据库使用一台 SUN5500 服务器。使用这种配置结构，在选课系统运行的高峰期间，经常出现系统响应速度慢， OAS 死机等情况。

根据上述结论，我们对选课系统的系统配置进行了结构调整。我们估算到在选课高峰时段，会有 2400 位学生同时选课，为了保证页面响应时间在 10 秒钟以内，我们使用了 4 台 OAS4 ，服务器分别为两台 Sun Enterprise 3000 、一台 Sun Enterprise 5000 和一台 Sun Enterprise 250 。在 4 台 OAS4 之前，我们还使用 PHP 做了一个简单的用户分配器，引导用户平均分配到 4 台 OAS4 上。按照这个系统配置，解决了以往选课系统在运行高峰时段平均响应速度慢的问题，取得了良好的使用效果 [4] 。