高校统一身份认证系统集群压力测试研究

文/冯兴利 洪丹丹 罗军锋 锁志海

随着信息化建设的普及，各高校自主研发的信息管理系统越来越多，比如OA办公自动化系统，为了鉴别登录系统的用户身份，身份认证系统不可或缺。统一身份认证系统使得用户可以使用唯一的NetID登录学校几乎所有信息系统，避免了多个账号带来的混乱，也使得其他应用系统对用户账号的管理更加便捷。

西安交通大学统一身份认证系统（简称CAS）作为学校其他应用系统的统一认证入口，面向全部在校师生，主要为应用系统提供身份鉴别、用户信息查询等服务。目前，西安交通大学研究生管理系统、学生选课系统、本科教务管理系统等多个系统网站都使用基于统一身份认证平台的单点登录系统。只需登录一次就可以访问校内受统一身份认证保护的各项服务，为师生带来了极大的便利[1]。截至目前，全校共有310个系统接入了统一身份认证平台。

统一身份认证系统在给全校师生提供登录便利的同时，也给自身服务器带来了强大的压力。为此，本文使用Loadrunner 11产生虚拟用户（Virtual users）来模拟实际用户对CAS系统施加压力，进一步寻找系统的优化空间[2]。

Web性能指标

在Web应用程序的开发中，研发人员在保证项目如期完成的同时，也在关注着程序的性能和可靠性。优化Web应用程序需要参考资源使用情况、浏览器兼容性等多项性能指标。而在Loadrunner中，衡量Web前端性能通常使用以下三个指标：

1.事务响应时间

事务的响应时间是执行一个操作所需要花费的时间，一定程度上反映了服务器的处理速度。

业内流行的网站响应时间评价标准为：2秒之内被认为是“非常有吸引力”的用户体验；5秒之内被认为是“比较不错”的用户体验；10秒之内被认为是“糟糕”的用户体验；超过10秒还没有得到响应，那么大多数用户会认为这次请求是失败的[3]。

2.每秒点击次数

每秒点击次数是指用户每秒向Web服务器提交的HTTP请求的个数，通过该项指标可以评估用户产生的负载量。

3.吞吐量

吞吐量代表用户每秒从服务器获得的数据量，单位是字节。根据服务器的吞吐量可以评估服务器在Web流量方面的处理能力[4]。

集群测试环境配置

本次测试准备9台虚拟机，其中一台作为主控机，其他8台作为负载机[5]。主控机上安装完整版的Loadrunner 11，所有负载机上安装负载发生器loadrunner generator，同时配置Loadrunner agent runtime settings configuration，所有虚拟机启动loadrunner agent process。测试步骤如下：

1.采用HTML Based方式录制脚本

在主控机上进行脚本的录制，因网站采用HTTPS协议，故录制脚本前需要对端口映射进行配置，并配置好客户端指定的.pem格式的证书，之后即可开始录制脚本[6]：打开统一身份认证登录页面，输入账号密码，点击登录（事务login开始），登录后返回登录成功页面（事务login结束）。录制成功的脚本中包含了证书部分，如下：

对录制好的脚本进行修改，将登录用户名和密码参数化，并添加检查点，保证所有用户都能登录成功，避免因部分用户账户或密码错误影响系统性能，同时对脚本中的参数JSESSIONID3进行关联[7]。关联方法如下：

2.配置测试场景

因每年的本科新生选课为统一身份认证并发量最多的一个阶段，每年新入校学生为4600人左右，故本次测试最多模拟5000人并发登录系统。

在主控机中模拟100,500,1000,……,5000个用户同时并发登录系统，要求瞬时并发，以完成登录操作、返回登录成功页面为准。为了更好模拟用户的使用习惯、节省时间和网络带宽资源，在进行场景配置时忽略Thinktime时间、出现错误仍继续、不下载如js/css/图片等非HTML资源、每次迭代不模拟新用户、不清除缓存，以便测试结果更接近实际情况[4]。

3.连接主控机与负载机

在主控机的Loadrunner generator中添加8个负载机，并进行连接测试，连接就绪后即可进行负载测试。

测试结果与分析

本次测试分别模拟100,500,1000,……,5000个用户同时并发登录系统，以1000个用户瞬时并发登录系统为例，测试结果分析概要如图1所示。

图1显示：1000个用户并发登录系统总计用时36s，平均响应时间为0.067s，平均每秒点击次数未189.189次，平均吞吐量时962,027字节/秒，事务成功率为100%。90%的用户登录的平均响应时间在0.103s以下。由此可见，当1000个用户并发登录系统时，服务器的平均响应时间很短，响应用户请求的速度极快。

图1 1000个用户同时登录系统的测试结果

图2 运行用户数和平均事务响应时间关联

图3 吞吐量和每秒点击次数

图2为1000用户并发登录系统时，运行用户数和平均事务响应时间的关联图，该图能够直观地反映出一方的变化对另一方的影响。随着运行用户数的增加，理论上平均响应时间应该越来越长。但图2显然不是这样，其原因在于：在并发测试的最后时刻，所有用户同时执行一个事务，但由于各个用户完成事务所用的时间长短不同，比较快完成事务的用户，在完成之后就先退出了系统，在这种情况下，系统中运行的用户数量越来越少，同时，由于这些用户完成事务比较慢、所用时间较长，Loadrunner计算事务的平均响应时间也就长了，所以就出现了图2中用户越少事务响应时间反而越长的情况。

图3是1000个用户并发登录系统时，吞吐量和每秒点击次数的叠加图。由于每秒点击次数反映了客户端每秒向服务器提交的请求数量。客户端发出的请求越多，服务器的吞吐量也应该越大，正常情况下，两者应该是一一对应成正比的关系。图3正好反映出这种关系，表明服务器能够及时准确处理客户端的请求。

上述是对1000个用户并发测试进行详细分析，接下来将对50,100，……，1000个用户并发测试的平均响应时间、平均每秒点击次数、平均吞吐量三个指标进行汇总和分析。

1. 平均响应时间

图4显示并发用户数与平均响应时间的关系，最佳性能的服务器其平均响应时间随着并发数的增加变得比较平缓。可以清晰看到，随着并发用户数的增加，平均响应时间增幅基本不变，表明系统的处理能力并没有随着并发用户数的增加而下降，非常稳定，未受到并发数增加的影响。且当并发用户数为5000时，平均响应时间为0.063s，用户体验非常好。

图4 并发用户数与平均响应时间

图5 并发用户数与平均每秒点击次数

图6 并发用户数与平均吞吐量

2. 平均每秒点击次数

图5表示并发用户数与平均每秒点击次数的关系。最佳性能的服务器每秒处理请求的个数是随着并发数的增加而增加的[8]。图中可以直观看到：服务器处理请求的个数随着并发数的增加有上升趋势，说明服务器处理能力不错，响应速度没有变慢，能够及时处理用户提交的HTTP请求。

3. 平均吞吐量

图6为并发用户数与平均吞吐量的关系。吞吐量即服务器每秒接受到的数据流量。理想状态下，服务器接受到的数据流量一定是随着并发数的增加而上升的[9]。该图清晰的表明当并发数增加的同时服务器接受的数据流量存在上升趋势。

图5和图6两条曲线走向基本一致，说明服务器能及时接受客户端提交的HTTP请求，并能正确返回请求结果[10]。

通过本次测试可看到，西安交通大学统一身份认证系统服务器完全可以承受5000个用户的并发登录。一般情况下，用户并发数相当于实际用户数的四分之一，即5000个用户同时并发登录系统，相当于20000个用户同时系统在线[11]。本次测试表明服务器完全可以承受20000个用户系统在线。由平均响应时间、平均吞吐量、平均每秒点击次数等软件性能指标可直观的看出网络性能非常优秀，客观地反映出服务器处理能力很好。有关服务器CPU、内存等硬件资源的监控，还需要在后续的测试中进一步监测分析。