性能测试方法指南

一、编写目的

本文档从性能工程的角度提出开展性能测试工作的流程，和进行性能测试工作的策略，以及针对promotion的性能测试方法指导；主要讨论性能测试的需求阶段、确立目标、设计阶段、用力场景设计、监控资源，和针对promotion项目的性能测试指南。

 

二、需求阶段

性能测试需求的来源

性能测试需求的来源有三个方面：

1、  需求文档

2、  设计文档

3、  客户备忘录

 

确定性能测试需求的解决方法

在没有需求文档和设计文档的情况下，我们需要对TSP系统上的客户业务使用情况进行分析，提出我们所关注的性能测试需求，并告知业务人员。让业务人员来判断我们的性能需求是否能满足客户的真实要求。

在通过TSP系统分析业务使用状况时，我们可以从以下方面来关注：

1、确定当前系统的业务使用状况：通过TSP的日志记录－客户端模块使用情况了解在某个时间段内，客户执行某个操作的具体情况。

2、了解不同视角的用户性能：

ⅰ）用户视角：

响应时间：用户所能感受到的响应时间，也是用户最重视的性能体验。

        确立响应时间的原则：2/5/10原则

                            2：2秒钟用户会觉得是一个很好的体验。

                            5：5秒钟用户可能会觉得差了一点，还行，比较好。

                            10：10秒钟是用户所能承受的最大极限。

鉴于不同地区的网络环境，将用户所能承受的响应时间极限定为12～15秒。

此部分需与业务人员讨论。

稳定性：系统长时间运行不会出现错误的能力。

验证方法：系统在满负载的运行8小时，系统是否会出现服务不可用，Connection Refused

      HTTP 404,500错误。

ⅱ）系统视角：延迟，系统资源使用状况

              延迟：包括数据库延迟和网络延迟

此部分需与DBA及系统部人员讨论。

              系统资源使用状况：服务器的CPU使用率是否长期高于80％，达到90％，100％的程度，整个磁盘的I/O是否达到极限。内存的使用数是否只剩下极少的几兆，几十兆。

ⅲ）开发者视角：从代码实现和数据库实现来考虑性能。看看这两方面得到实现是否足够好。

3、了解真正的性能测试需求

方法：ⅰ）识别项目干系人：指的是和项目相关的人，开发人员，设计人员，需求人员，业务人员，上层领导，了解他们对性能测试的考虑。

      ⅱ）隐藏在“性能测试”之后的实际想法，比如：是因为开发人员对所完成的代码没有信心，又不愿意做修改，要求我们对其所作的程序进行性能测试，还是设计人员使用了一项新技术，心里没低，所要求作的性能测试，等等。

 

三、确立性能测试目标

确立性能测试目标的原则

1、以“需求”为本

考虑系统需不需要作性能测试，性能测试的内容和范围。

2、测试目标确定的经济性考虑

ⅰ）投入到性能测试的人员是多少？

ⅱ）具备可以确定性能测试需求，制定性能测试方案的人员是多少？可以执行性能测试的人员是多少？

ⅲ）这些人员需要投入多长时间？

ⅳ）所要开发系统的运行环境和设备，这些设备的配置对于性能测试的影响，比如说：tomcat4.1的应用服务器，它的配置文件缺省的jvm的使用空间是64M，一个机器的内存为1G，我们将jvm的使用空间设置为512M对性能测试的影响。

ⅴ）内部的人员无法满足性能测试的要求，通过外聘，采用外聘的方式，公司所能承受的成本是多高。

 

3、基于风险的测试目标确定

ⅰ）系统如果不做性能测试，会有多大的风险，如果在性能指标上达不到用户的要求会有多大的风险。需要进行评估。

ⅱ）如果做性能测试会有多大的风险，性能测试的投入会有多大，会有多大的风险需要进行评估。

确定性能测试目标的方法

我们要确定系统的吞吐量和并发用户数的设计目标可以采用以下三种方式：

l  确定在某个特定时间端内，估计系统会有多少用户同时访问

l  在某个特定的时间端内，正在访问系统的用户的典型操作是什么？哪个页面的访问量最大？

l  在某个特定的时间端内，系统需要处理多少种用户场景

这些数据可以在系统服务器的日志文件、TSP监视数据种找到，也可以通过监视数据库的活动情况来获得。

四、设计阶段

性能测试方案的确立

在确立性能测试方案之前，需要作的工作

1、确定测试目标和需求

这里的灵活性比较大，与性能测试成败有很大的关系。

2、了解现状

ⅰ）业务使用状况

通过日志记录，在某个时间段内，用户的操作。

ⅱ）了解环境：包括网络条件，服务器条件，软硬件条件，应用服务器环境及各种配置信息。

 

3、确定需要监控的指标：

ⅰ）CPU使用率

ⅱ）内存使用情况

在此应优先监控应用服务器的性能指标。对于Tomcat或者Weblogic来说，监控他的JVM使用状况，连接池的连接数量，内存使用状况等信息。对于数据库来说监控cache的命中率，索引的使用状况，数据库的连接数。

 

五、用例和场景设计

用例和场景设计的步骤：

1、对业务的分析和分解

2、根据业务确定用例

3、不同用例按照不同的发生比例组成场景 

4、了解每个场景的实际意义（对场景执行测试，收集结果）

了解业务的分布情况，根据业务确定用例，在设计用例的时候，根据前期收集的数据，设计不同的场景来组成用例，并了解每个场景的实际意义，执行场景，收集结果数据。

场景设计的例子（主要是根据业务的使用状况）：

l  场景1：10％登录，10％入库，30％订单，20％出库，30％查询（1000用户）——日常

l  场景2：10％登录，90％查询（400用户）——周末盘点

 

六、设定需要监控的资源

设定需要监控的资源主要有一下几个方面：

1、CPU利用率

2、内存使用情况

3、数据库监控

4、JVM使用状况监控

应优先监控应用服务器的性能指标。对于Tomcat或者Weblogic来说，监控他的JVM使用状况，连接池的连接数量，内存使用状况等信息。对于数据库来说，cache的命中率，索引的使用状况，数据库的连接数，具体的监控指标请性能测试工程师，根据性能需求确定。

 

 

 

七、Promotion性能测试指南

系统概述

本文主要是描写针对Media Promotion营销系统各个功能进行性能测试的基本方法。

Media Promotion营销系统能让运营商简单方便地进行内容营销（包括彩铃、振铃、全曲、视频）。系统能够根据营销任务定期向目标用户群组发送营销短信、彩信或邮件，用户还可以根据需要在系统中配置挂机短信营销任务和事件触发短信营销任务。

测试目标

本次性能测试的目的是验证Media Promotion营销系统在大量用户量情况下，营销任务的速率符合要求。具体测试方案是通过对群发短信/彩信的性能测试，观察系统资源的表现以及各步骤响应时间，以确定Media Promotion营销系统的性能。

根据使用场景分析，Media Promotion营销系统中使用频率比较高的功能主要是：增加群组、群发短信、群发彩信、挂机短信。

系统分析

Media Promotion双机组网

Media Promotion压力传递

通过压力传递分析，确定潜在瓶颈如下：

1、数据库的性能：Web页面向数据库发出操作请求，数据库的响应速度将直接影响到Web页面处理请求的速度。很多后台处理在存储过程中实现，压力也随之分摊到了数据库，另外，一些低效的SQL语句，冗余的表结构等等都会成为妨碍数据库应用性能的一个因素，因此数据库的性能也可能会是影响系统性能的瓶颈。

2、营销任务处理的性能：在大数据量的情况下，线程扫描任务记录是否准确并及时发送，以及媒体网关的处理能力可能存在性能瓶颈。

3、接口性能：在大数据量的情况下，接口调用的及时响应时也是影响WEB查询、营销任务处理的性能瓶颈。

1  性能环境调优

   

2  性能环境搭建

参考各版本安装指导书。

3  性能测试方法

1       

2       

3       

3.1      添加群组(自定义群组)

1、流程分析：管理员通过Web页面创建自定义用户群组包括文件导入、添加散列号码、添加号段，系统根据配置项“子群组所包含最大的号码数量”、“全局号段匹配值”，将用户信息写入数据库T_PUSH_GROUPINFO、T_PUSH_SUBGROUPINFO、T_PUSH_GROUPMEMBER表，并操作日志写入T_PUSH_BATCH_OPERATION_LOG表。

2、数据构造：

3、资源观察：

运行时长(秒)、平均每秒入库(条)、成功数

select (max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24 column1,

       count(*) / ((max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24) column2,

       count(*) column3

  from t_push_groupmember t

 where groupid in (select groupid

                     from t_push_groupinfo

                    where groupname = '创建的群组名称')

并行任务时，执行以下语句

select (max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24 column1,

         count(*) /

         ((max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24) column2,

         count(*) column3

from t_push_groupmember t

where groupid in (select groupid

                       from t_push_groupinfo

                      where (groupname = '创建的群组名称1' or groupname = '创建的群组名称2'))

需要保证创建的群组名称不同。

根据实际创建的群组名称，替换蓝色部分。

仅支持多记录一次性增加的情况。

CPU占用(%)

sar -P ALL 2 0 > CPU.txt

"2"表示时间间隔为2s，"0"表示收集总次数，如果为0则表示无限次，如果>0则在执行完指定的次数后自动退出；后面的">"符号表示把数据输出到CPU.txt文件，测试后完成后，我们对CPU.txt文件进行分析即可。

内存占用(MB)

sar -r 2 0 > MEM.txt

"2"表示时间间隔为2s，"0"表示收集总次数，如果为0则表示无限次，如果>0则在执行完指定的次数后自动退出；后面的">"符号表示把数据输出到MEM.txt文件，测试后完成后，我们对MEM.txt文件进行分析即可。

3.2     群发短信

1、流程分析：管理员通过Web页面创建通知类群发短信营销任务，保存在数据库t_push_sendsms表；

系统根据配置项“短信群发线程数配置”、“营销任务群发任务发送时，每台portal上启动的发送短信线程数”的线程数，从T_PUSH_GROUPMEMBER表获取成员号码，每个线程获取号码数量由“子群组所包含最大的号码数量”控制；

从t_content_rbtinfo表获取回复类歌曲内容；

根据“发送限制方式”、“限制名单”配置，发送线程将数据取到内存，处理完成后将结果写入t_rule_batchsendsmlog表。

2、数据构造：

3、资源观察：

发送时长(秒)、发送速率(条/秒)、总发送数、成功数

     select

               t1.column1, t1.column2, t1.column3, t2.column4

       from ((select

                             (max(t.time) - min(t.time)) * 60 * 60 * 24 column1,

                             count(*) / ((max(t.time) - min(t.time)) * 60 * 60 * 24) column2,

                             count(*) column3

                   from t_rule_batchsendsmlog t

                   where smsid = id)

               ) t1,

               (select

                           count(*) column4

                from t_rule_batchsendsmlog t

                where smsid = id

                    and result = 0

               ) t2;

并行任务时，执行以下语句（时间是最早开始，最晚结束）

select

           t1.column1, t1.column2, t1.column3, t2.column4

  from ((select

                       (max(t.time) - min(t.time)) * 60 * 60 * 24 column1,

                       count(*) / ((max(t.time) - min(t.time)) * 60 * 60 * 24) column2,

                       count(*) column3

               from t_rule_batchsendsmlog t

            where (smsid = id1 or smsid =id2)

                        and t.time >= to_date(' 2011-10-25 18:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')

                        and t.time <= to_date(' 2011-10-25 20:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')

           )

         ) t1,

         (select

                     count(*) column4

            from t_rule_batchsendsmlog t

         where (smsid = id1 or smsid =id2)

                    and result = 0

                    and t.time >= to_date(' 2011-10-25 18:00:00', 'SYYYY-MM-DD HH24:MI:SS')

                    and t.time <= to_date(' 2011-10-25 20:00:00', 'SYYYY-MM-DD HH24:MI:SS')

         ) t2;

根据实际创建的营销任务id，替换蓝色部分。

根据实际的并发开始时间、结束时间替换替换蓝色部分。

仅支持多记录一次性增加的情况。

CPU占用(%)

sar -P ALL 2 0 > CPU.txt

"2"表示时间间隔为2s，"0"表示收集总次数，如果为0则表示无限次，如果>0则在执行完指定的次数后自动退出；后面的">"符号表示把数据输出到CPU.txt文件，测试后完成后，我们对CPU.txt文件进行分析即可。

内存占用(MB)

sar -r 2 0 > MEM.txt

"2"表示时间间隔为2s，"0"表示收集总次数，如果为0则表示无限次，如果>0则在执行完指定的次数后自动退出；后面的">"符号表示把数据输出到MEM.txt文件，测试后完成后，我们对MEM.txt文件进行分析即可。

3.3      群发彩信

1、流程分析：管理员通过Web页面创建群发彩信营销任务，保存在数据库t_push_mmstask表。

系统根据配置项“彩信群发线程数配置”的线程数，从T_PUSH_GROUPMEMBER表获取成员号码，每个线程获取号码数量由“子群组所包含最大的号码数量”控制；

根据“发送限制方式”、彩信内容模板，从“彩信内容文件存放路径”获取彩信内容，发送线程将数据取到内存；

处理完成后将结果写入t_push_logsendmms表。

发送流程图，与群发彩信一致。

2、数据构造：

3、资源观察：

发送时长(秒)、发送速率(条/秒)、总发送数、成功数

select

          t1.column1, t1.column2, t1.column3, t2.column4

  from ((select

                        (max(t.time) - min(t.time)) * 60 * 60 * 24 column1,

                        count(*) / ((max(t.time) - min(t.time)) * 60 * 60 * 24) column2,

                        count(*) column3

              from t_push_logsendmms t

              where mmstaskid = id)

          ) t1,

          (select

                      count(*) column4

           from t_push_logsendmms t

           where mmstaskid = id

               and result = 0

          ) t2;

并行任务时，执行以下语句

select

           t1.column1, t1.column2, t1.column3, t2.column4

  from ((select

                       (max(t.time) - min(t.time)) * 60 * 60 * 24 column1,

                       count(*) / ((max(t.time) - min(t.time)) * 60 * 60 * 24) column2,

                       count(*) column3

               from t_push_logsendmms t

            where (mmstaskid = id1 or mmstaskid =id2)

                        and t.time >= to_date(' 2011-10-25 18:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')

                        and t.time <= to_date(' 2011-10-25 20:00:00', 'SYYYY-MM-DD HH24:MI:SS')

           )

         ) t1,

         (select

                     count(*) column4

            from t_push_logsendmms t

         where (mmstaskid = id1 or mmstaskid =id2)

                    and result = 0

                    and t.time >= to_date(' 2011-10-25 18:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')

                    and t.time <= to_date(' 2011-10-25 20:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')

         ) t2;

根据实际创建的营销任务id，替换蓝色部分。

根据实际的并发开始时间、结束时间替换替换蓝色部分。

仅支持多记录一次性增加的情况。

CPU占用(%)

sar -P ALL 2 0 > CPU.txt

"2"表示时间间隔为2s，"0"表示收集总次数，如果为0则表示无限次，如果>0则在执行完指定的次数后自动退出；后面的">"符号表示把数据输出到CPU.txt文件，测试后完成后，我们对CPU.txt文件进行分析即可。

内存占用(MB)

sar -r 2 0 > MEM.txt

"2"表示时间间隔为2s，"0"表示收集总次数，如果为0则表示无限次，如果>0则在执行完指定的次数后自动退出；后面的">"符号表示把数据输出到MEM.txt文件，测试后完成后，我们对MEM.txt文件进行分析即可。

3.4      挂机短信

1、流程分析：管理员通过Web页面创建挂机短信营销任务，保存在数据库t_push_hangsm表。

系统根据挂机短信ftp配置信息，从ftp服务器获取挂机话单，并将话单信息保存到数据库t_push_ds_offlinefileinfo表；

解析话单文件，根据创建的营销任务，连接USDP数据库对用户状态进行判断，并根据配置项“创建挂机短信群组时，一个子群组所包含最大的号码数量”将发送记录保存到t_push_ds_offlinesms_x(x为1-7的数字)表，对应的群组信息保存到t_push_ds_offlinegroupinfo_x(x为1-7的数字)表；

根据配置项“短信群发线程数配置”的线程数，从t_push_ds_offlinesms_x(x为1-7的数字)表获取发送信息，每个线程获取号码数量由“创建挂机短信群组时，一个子群组所包含最大的号码数量”控制；

根据“发送限制方式”、“限制名单”、“挂机发送号段配置”配置，发送线程将数据取到内存，处理完成后将结果写入t_rule_hangupsendsmlog表。

2、数据构造：

3、资源观察：

运行时长(秒)、平均每秒入库(条)、成功数

select (max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24 column1,

       count(*) / ((max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24) column2,

       count(*) column3

  from t_push_groupmember t

 where groupid in (select groupid

                     from t_push_groupinfo

                    where groupname = '创建的群组名称')

并行任务时，执行以下语句

select (max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24 column1,

         count(*) /

         ((max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24) column2,

         count(*) column3

from t_push_groupmember t

where groupid in (select groupid

                       from t_push_groupinfo

                      where (groupname = '创建的群组名称1' or groupname = '创建的群组名称2'))

需要保证创建的群组名称不同。

根据实际创建的群组名称，替换蓝色部分。

仅支持多记录一次性增加的情况。

CPU占用(%)

sar -P ALL 2 0 > CPU.txt

"2"表示时间间隔为2s，"0"表示收集总次数，如果为0则表示无限次，如果>0则在执行完指定的次数后自动退出；后面的">"符号表示把数据输出到CPU.txt文件，测试后完成后，我们对CPU.txt文件进行分析即可。

内存占用(MB)

sar -r 2 0 > MEM.txt

"2"表示时间间隔为2s，"0"表示收集总次数，如果为0则表示无限次，如果>0则在执行完指定的次数后自动退出；后面的">"符号表示把数据输出到MEM.txt文件，测试后完成后，我们对MEM.txt文件进行分析即可。

3.5      短信回复(开户类)

1、流程分析：。

2、数据构造：

3、资源观察：

3.6      短信回复(下载类)

1、流程分析：。

2、数据构造：

3、资源观察：

3.7      数据同步(规则群组)

1、流程分析：。

2、数据构造：

3、资源观察：

3.8      数据同步(动态歌曲)

1、流程分析：。

2、数据构造：

3、资源观察：