2．1项目背景
人力资源上线初期，由于全省40多个电业局临时决定同时集中使用人力资源系统，这是开发初期没有想到的事情，所以用户刚刚使用就反映整个系统速度很慢，项目组和公司领导层高度重视这个事情，可是究竟慢在什么地方呢？是什么原因引起的慢，面对一个这么庞大而复杂的系统，要想找到真正的原因是很难办到的事情，大家都在怀疑和猜测着？是硬件问题？还是应用服务器慢？还是数据库服务器慢呢？围绕这一系列的疑问，性能测试工作紧张又有条不紊的展开了，而测试组担负着性能测试的主要重担，于是安排舒文林负责这个事情。
2．2测试流程
测试组接到任务过后，进行一系列的思考，确定了将整个系统逐步分解的测试办法，就是先将系统分成几个大块，应用服务器，数据库服务器，客户端程序；然后再将服务器拆成硬件和软件；然后逐步将应用软件划分成若干逻辑层，测试组舒文林经过和项目组沟通过后，首先找几个最慢的功能登陆，分页，人员子集编辑信息，组织机构查询。通过80人摸拟以上操作同时访问人力资源系统，在这样的情况下，我们发现压力主要集中在数据库服务器上，值得庆兴的是，通过观察应用服务器CPU，内存，磁盘，网络等资源，一切正常，所以我们排除了应用服务器引起慢的可能，把注意力集中在数据库服务器上。
再观察数据库服务器时，我们发现CPU一直处于100%，磁盘I/O很慢，每秒在283K左右。于是直接想到的是换硬件，开发组决定更换磁盘阵列卡，将数据库服务器改成IBM的高档小型机。这样性能得到了一定的提升，但过了不久，用户又开始有意见了 ，那说明我们现在的系统性能还没有达到用户的要求，公司领导层再次组织进行性能测试，说的是一定要挖掘深层次的原因。
于是测试组又派出了舒文林负责人力资源项目的性能测试，此时项目组要到了验收的时候了，这不免无形中给测试组增加了很大的压力， 这个时候Sybase工程师也来了，怎么办呢？还是老办法吧，不过这次我们是先从功能作为分解点，先找到最慢的功能，一个一个的测试/首先找到的是登陆，我们把登陆功能按照程序逻辑拆分成若干小的功能，及显示登陆页面，权限验证，加载主菜单、主画面等，结果发现登陆功能最慢的是加载主菜单和权限验证这两块，消耗了整个登陆功能大部份的时间，那就给开发人员找到了优化的地方，通过使用高速缓存，建立数据库索引，优化SQL，优化程序等技术手段过后，登陆功能性能提升了一半；最大支持用户数也由120增加到了200，接下来按照老办法，开始分页功能的测试，由于Sybase使用分页必须使用临时表，先将要分页的数据放到临时表，页面显示层再从临时表里面取出数据填充到客户端显示，
还是先用80个用户同时使用该系统分页，并重复迭带多次，这个时候CPU长时间饱和，客户端时间很满，达到70秒，先记录作为基准测试。
再看数据库的各种指标，我们发现数据库有严重的阻塞，终于有了根本性的发现。Sybase工程师想到通过绑定多个临时表，并通过ASE的同步机制来保持同步，这样阻塞问题缓解了，响应时间也由70秒降到了30秒。但是当用户数增加到120的时候，数据库CPU又是100%，系统又慢了下来，而且系统其它功能也都慢了下来，我们分析了一下，觉得通过增加多个临时表和多个临时库，这样会不会带来额外的CPU开销呢？肯定会的，但这个开销究竟有好大呢？这是一个还没有确定的问题？如果CPU开销小了，系统性能肯定会好起来，因为目前就CPU是个瓶劲。
这个时候，Sybase工程师说他们已经做到最优化了，而开发人员也觉得他们该做的都做了，那为什么现在系统还慢呢？凭我的经验，我觉得这笔开销很大，但我又无法证明这一点，Sybase工程师承认这需要额外的CPU和内存开销，但究竟多大，也是一个疑问。为了弄清楚这个问题，我们选在在同一台计算机上将分页的功能做一个比较，我们抛开应用服务器，通过直接测试分页脚本，来比较各自的性能。采取在该服务器上全新安装操作系统和必要的软件，做成Ghost恢复文件。
然后分别测试Sybase和Oracle，首先安装Sybase产品，进行测试后，然后用Ghost恢复系统到初始化环境，安装Oracle，采用和Sybase相同的测试案例进行测试， 并将oracle和Sybase调整到最优化，最后将两个测试结果汇总，测试过程忽略不计，结论是Sybase进行翻页CPU是100，而oracle是25%，Oracle分页由于有ROWNUM字段，所以不需要使用临时表，响应时间都在40秒左右，因为我们找的计算机很普通，所以时间长了点，所以我们得出Sybase使用临时表分页消耗CPU很大的结论，人力资源系统性能的测试和研究在以后的历程中，任务将会更加艰巨，我们完全有信心克服困难，战胜困难，因为我们已经积累了很多经验。待续。。。
文章来源于领测软件测试网 https://www.ltesting.net/
