性能测试实战总结

1项目背景
        人力资源上线初期&＃xff0c;由于全省40多个电业局临时决定同时集中使用人力资源系统&＃xff0c;这是开发初期没有想到的事情&＃xff0c;所以用户刚刚使用就反映整个系统速度很慢&＃xff0c;项目组和公司领导层高度重视这个事情&＃xff0c;可是究竟慢在什么地方呢&＃xff1f;是什么原因引起的慢&＃xff0c;面对一个这么庞大而复杂的系统&＃xff0c;要想找到真正的原因是很难办到的事情&＃xff0c;大家都在怀疑和猜测着&＃xff1f;是硬件问题&＃xff1f;还是应用服务器慢&＃xff1f;还是数据库服务器慢呢&＃xff1f;围绕这一系列的疑问&＃xff0c;性能测试工作紧张又有条不紊的展开了&＃xff0c;而测试组担负着性能测试的主要重担&＃xff0c;于是安排舒文林负责这个事情。

        2测试流程

        测试组接到任务过后&＃xff0c;进行一系列的思考&＃xff0c;确定了将整个系统逐步分解的测试办法&＃xff0c;就是先将系统分成几个大块&＃xff0c;应用服务器&＃xff0c;数据库服务器&＃xff0c;客户端程序&＃xff1b;然后再将服务器拆成硬件和软件&＃xff1b;然后逐步将应用软件划分成若干逻辑层&＃xff0c;测试组舒文林经过和项目组沟通过后&＃xff0c;首先找几个最慢的功能登陆&＃xff0c;分页&＃xff0c;人员子集编辑信息&＃xff0c;组织机构查询。通过80人摸拟以上操作同时访问人力资源系统&＃xff0c;在这样的情况下&＃xff0c;我们发现压力主要集中在数据库服务器上&＃xff0c;值得庆兴的是&＃xff0c;通过观察应用服务器CPU&＃xff0c;内存&＃xff0c;磁盘&＃xff0c;网络等资源&＃xff0c;一切正常&＃xff0c;所以我们排除了应用服务器引起慢的可能&＃xff0c;把注意力集中在数据库服务器上。

        再观察数据库服务器时&＃xff0c;我们发现CPU一直处于100%&＃xff0c;磁盘I/O很慢&＃xff0c;每秒在283K左右。于是直接想到的是换硬件&＃xff0c;开发组决定更换磁盘阵列卡&＃xff0c;将数据库服务器改成IBM的高档小型机。这样性能得到了一定的提升&＃xff0c;但过了不久&＃xff0c;用户又开始有意见了 &＃xff0c;那说明我们现在的系统性能还没有达到用户的要求&＃xff0c;公司领导层再次组织进行性能测试&＃xff0c;说的是一定要挖掘深层次的原因。

        于是测试组又派出了舒文林负责人力资源项目的性能测试&＃xff0c;此时项目组要到了验收的时候了&＃xff0c;这不免无形中给测试组增加了很大的压力&＃xff0c; 这个时候Sybase工程师也来了&＃xff0c;怎么办呢&＃xff1f;还是老办法吧&＃xff0c;不过这次我们是先从功能作为分解点&＃xff0c;先找到最慢的功能&＃xff0c;一个一个的测试/首先找到的是登陆&＃xff0c;我们把登陆功能按照程序逻辑拆分成若干小的功能&＃xff0c;及显示登陆页面&＃xff0c;权限验证&＃xff0c;加载主菜单、主画面等&＃xff0c;结果发现登陆功能最慢的是加载主菜单和权限验证这两块&＃xff0c;消耗了整个登陆功能大部份的时间&＃xff0c;那就给开发人员找到了优化的地方&＃xff0c;通过使用高速缓存&＃xff0c;建立数据库索引&＃xff0c;优化SQL&＃xff0c;优化程序等技术手段过后&＃xff0c;登陆功能性能提升了一半&＃xff1b;最大支持用户数也由120增加到了200&＃xff0c;接下来按照老办法&＃xff0c;开始分页功能的测试&＃xff0c;由于Sybase使用分页必须使用临时表&＃xff0c;先将要分页的数据放到临时表&＃xff0c;页面显示层再从临时表里面取出数据填充到客户端显示&＃xff0c;


        还是先用80个用户同时使用该系统分页&＃xff0c;并重复迭带多次&＃xff0c;这个时候CPU长时间饱和&＃xff0c;客户端时间很满&＃xff0c;达到70秒&＃xff0c;先记录作为基准测试。
        再看数据库的各种指标&＃xff0c;我们发现数据库有严重的阻塞&＃xff0c;终于有了根本性的发现。Sybase工程师想到通过绑定多个临时表&＃xff0c;并通过ASE的同步机制来保持同步&＃xff0c;这样阻塞问题缓解了&＃xff0c;响应时间也由70秒降到了30秒。但是当用户数增加到120的时候&＃xff0c;数据库CPU又是100%&＃xff0c;系统又慢了下来&＃xff0c;而且系统其它功能也都慢了下来&＃xff0c;我们分析了一下&＃xff0c;觉得通过增加多个临时表和多个临时库&＃xff0c;这样会不会带来额外的CPU开销呢&＃xff1f;肯定会的&＃xff0c;但这个开销究竟有好大呢&＃xff1f;这是一个还没有确定的问题&＃xff1f;如果CPU开销小了&＃xff0c;系统性能肯定会好起来&＃xff0c;因为目前就CPU是个瓶劲。

        这个时候&＃xff0c;Sybase工程师说他们已经做到最优化了&＃xff0c;而开发人员也觉得他们该做的都做了&＃xff0c;那为什么现在系统还慢呢&＃xff1f;凭我的经验&＃xff0c;我觉得这笔开销很大&＃xff0c;但我又无法证明这一点&＃xff0c;Sybase工程师承认这需要额外的CPU和内存开销&＃xff0c;但究竟多大&＃xff0c;也是一个疑问。为了弄清楚这个问题&＃xff0c;我们选在在同一台计算机上将分页的功能做一个比较&＃xff0c;我们抛开应用服务器&＃xff0c;通过直接测试分页脚本&＃xff0c;来比较各自的性能。采取在该服务器上全新安装操作系统和必要的软件&＃xff0c;做成Ghost恢复文件。

        然后分别测试Sybase和Oracle&＃xff0c;首先安装Sybase产品&＃xff0c;进行测试后&＃xff0c;然后用Ghost恢复系统到初始化环境&＃xff0c;安装Oracle&＃xff0c;采用和Sybase相同的测试案例进行测试&＃xff0c; 并将oracle和Sybase调整到最优化&＃xff0c;最后将两个测试结果汇总&＃xff0c;测试过程忽略不计&＃xff0c;结论是Sybase进行翻页CPU是100&＃xff0c;而oracle是25%&＃xff0c;Oracle分页由于有ROWNUM字段&＃xff0c;所以不需要使用临时表&＃xff0c;响应时间都在40秒左右&＃xff0c;因为我们找的计算机很普通&＃xff0c;所以时间长了点&＃xff0c;所以我们得出Sybase使用临时表分页消耗CPU很大的结论&＃xff0c;人力资源系统性能的测试和研究在以后的历程中&＃xff0c;任务将会更加艰巨&＃xff0c;我们完全有信心克服困难&＃xff0c;战胜困难&＃xff0c;因为我们已经积累了很多经验。