性能测试案例01-视频网站

1.背景

已经上线的视频网站遇到的性能问题。该系统的设计目标是满足每天150WPV(页面浏览量)。在上线后,由于用户并发量较大,CPU的利用率经常高居100%,导致Oracle数据库发生停止服务的现象。数据库不工作,网站运营人员就无法维护系统,甚至导致终端用户不能正常访问网站。

2.体系结构:

2.1视频发布系统

一个成型的产品,主要功能是建立一个运营平台,把视频发布到系统中,并为门户提供接口。

2.2网站门户

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

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

3.1测试目标:

找出导致数据库停止服务的原因:程序算法上的缺陷或者数据库配置不正确。算法上的缺陷会导致CPU资源过度消耗,而配置不正确也会引起数据库系统运行异常。

3.2用例设计

1. 把对数据库的操作分为Insert、Update、Delete、Select四种操作,分别隔离进行测试,以定位哪种操作容易引起问题

2. 把用户的日常操作模拟出来,也就是把用户对数据库的操作组合起来进行测试。

3. 做一些疲劳强度或者大数据量的压力测试,以使问题快速重现。

4. 业务分析: 
        网站门户用户访问量较大的主要有三个页面:
        1.  视频首页
            视频首页是导航页面,主要操作有查找视频或者自己关注的视频、进入二级分类页面、进入播放页面
        2.   收费播放页面
            付费用户播放视频时候进入的页面
        3.   免费播放页面
            用户播放免费视频时候进入的页面

3.3 测试实施过程

  1. 测试环境

  2. 常规并发用户测试 本案例中先选择50个并发用户来观察系统的性能表现,得出结论:视频首页Index不能访问,收费播放页面(PLAY访问)的平均访问时间为181.834秒。 解决措施:先从系统的参数配置或者硬件配置入手,然后再分析软件自身原因。这样做是因为参数配置不正确的错误很容易纠正,更是常见的性能问题的原因,而分析软件本身则是后面测试工作的主要内容。查看了oracle的服务器配置后,立刻发现一个参数配置问题:Oracle数据库的运行模式是“专有服务器模式”,而“共享服务器模式”才是相对更适合大规模并发的模式。

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

  3. 独立场景测试 下面是Oracle调成了“共享服务器模式”后的测试实施过程。只针对播放页面来进行。800个用户并发、压力持续30分钟的测试结果“Summary”

    通过这个图可以看到“Action”事务即打开播放页面的平均时间是1.354秒。这是非常好的结果,但是更应该注意到:半个小时内超过17万个播放页面不能正常打开,同时可以计算出“打开播放页面”事务仅仅82%的通过率。 继续更长时间的场景测试:900-用户;1.5h

    可以看到“Action”事务“打开播放页面”的平均响应时间为1.438秒,这是用户量变大之后的正常反应。事务通过率为85%,与82%没有太大变化。可能是服务器缓存造成的。

    打开Oracle的管理工具,借助Oracle提供的工具进行分析:

    “发现SQL语句消耗了大量数据库时间”,发现恰恰是播放页面频繁使用的语句。

    根据推理:SQL语句小号了大量的数据库时间,其他原因极有可能是语句不合理引起的。主要推理如下:当一些反复执行的SQL语句效率过低时,首先会造成高速缓存不够用,随之引起较大的I/O;而频繁的I/O势必会消耗大量的CPU。因此整个系统的瓶颈很可能是这三个语句造成的。 再借助“Analysis”“事务平均响应时间图”和“建立第一缓冲的时间分解图”可以得出一下结论: 1. 事务平均响应时间文稳定,说明本次测试性能问题主要在程序自身。如果是服务器存在问题,则长时间的压力测试会导致响应时间越来越长。 2. “建立第一缓冲的时间”主要消耗在服务器上,说明对用户请求的处理方式不合理。

  4. SQL语句调整后的测试

    ![](/upload/media/markdown/15307900594232_1537439131548.jpg)
    
    ![](/upload/media/markdown/15307900941116_1537439147920.jpg)
    

    “事务平均响应时间图”可以看到整个测试过程“打开播放页面”的平均响应时间成平滑直线,系统的性能非常稳定。由此可以得出结论:调整SQL语句的策略是正确的。 我们可以看到事务平均响应时间变成了,本次是39秒。本次测试用的只是普通的PC服务器,900个并发用户1秒的响应时间显然不合理,而39秒才符合实际情况。

  5. 性能调优方案

  6. 系统配置方面: Oracle运行模式调成“共享服务器模式“;增大了分配给Oracle的内存,把内存调整成系统内存的55%;增大共享池(SHARED_POOL)和缓冲区高速缓存(DB_CACHE)的大小;对数据库表和查询相关的字段建立索引。

    1. 应用程序方面 用优化后的程序来替换原有程序;采用页面缓存技术来提高用户访问速度,同时减缓对数据库的压力。
  7. 线上的性能测试验证

    1. 页面无缓存、500个用户并发,6分钟,运行的最大用户数1000个。测试内容:打开任意视频进行播放。 本次测试结论如下: Oracle服务器CPU的平均利用率为82.723%,说明数据库系统稳定运行。Web服务器的CPU平均利用率为67.543%。如果按照一天8小时计算,一台服务器每天的PV值为:67.126X3600X8 =193w,足可以支撑150万的PV。

    2. 采用静态页面缓存方式、500个用户并发;6分钟;运行的最大用户数:1000个。测试内容:打开任意视频播放。

    本次测试结论如下:Oracle服务器的CPU的平均利用率非常低,为8.267%。这说明静态页面缓存技术大大节省了数据库的资源消耗,系统更加稳定运行。Web服务器的CPU平均利用率是67.323%。按照一天8小时计算。69.043X3600X8=199万。足可以支撑150万的PV。

4.总结

在进行性能分析与调优时,应该先从容易的地方入手。这样做的原因时可以先排出常见的、容易引起瓶颈的问题,避免各种因素环匝在一起不容易对问题进行定位。 在实际项目中,还应该注意的是要细心地查看Analysis的各种分析报表,不能让任何一个性能问题从眼皮底下溜掉。


评论(0 ) 点赞(19)


暂未登录,请登录之后发表评论。 QQ