物联网能耗监控项目性能测试报告V1.0.doc

文档编号
NH_XN_01
文档类别
测试文档
文档级别
高

中移动物联网能耗监控平台V2.0
性能测试报告
<V1.0>

文档修订记录
版本日期
版本
描述
作者
检查人/日期
备注
2015.06.29
1.0
创建文档
唐晓文

目 录
1 测试概述 4
1.1 项目背景 4
1.2 测试目的 4
1.3 术语、定义和缩略语 4
1.4 测试内容和范围 5
2 测试执行过程和结果 5
2.1 测试对象和测试环境 5
2.1.1 测试对象 5
2.1.2 网络拓扑结构 8
2.1.3 硬件及软件环境 9
2.2 测试策略和方法 10
2.3 测试工具及程序 12
2.4 系统资源监控及关注指标 12
2.5 测试结果 13
2.5.1 能耗监控平台 13
2.5.2 与设备云交互的数据收发模块 17
2.5.3 消息解析程序 18
2.5.4 定时任务 20
3 测试结论指标 22
4 测试总结 25
5 附录 25

第25页 共25页
1 测试概述
1.1 项目背景
能耗监控平台将主要从能耗分析、预估及对应节能策略入手，主要完成对能源终端的监控、管理、分析、预估，并根据以上数据进行对应节能策略配置的管理系统。平台主要功能详见《能耗监控平台V2.0需求规格说明书》。
1.2 测试目的
此次性能测试的目的是：通过在测试环境中，运用性能测试策略和测试工具对能耗监控平台的关键节点进行性能测试，最终得出各系统节点的性能情况指标数据，以此来对整个能耗监控系统性能做出评估。
1.3 术语、定义和缩略语
名称
解释
能耗监控系统
能耗监测系统是指通过对能耗设备和能耗建筑安装分类和分项能耗计量装置，采用物联网等技术手段及时采集能耗数据，实现重点建筑、设备能耗的在线监测和动态分析功能的硬件系统和软件系统的统称。
中移动物联网
设备云平台
中移设备云平台是指中移物联网有限公司自主研发的开放、共赢OneNET平台，为各种跨平台物联网应用、行业解决方案，提供简便的云端接入、存储、计算和展现。
响应时间
请求从发送开始到接收完服务器响应结果的时间
吞吐量
系统最大的每秒处理请求量，单位是：请求/秒

1.4 测试内容和范围
此次性能测试的内容和范围是整个能耗监控系统，从采集数据开始到能耗监控平台展现数据、维护设备、统计报表。能耗监控平台又分为前后台，由于后台使用频率较小，故不纳入此次性能测试范围。由于整个业务流程需要和设备云交互，虽然设备云不在此次测试范围内，但也需要模拟设备云向设备发起获取数据请求，测试整体业务性能。如发现由设备云引起的性能问题则推动外部解决，不作为此次测试的重点。此次只针对于能耗监控系统自身开发的功能或接口服务程序进行测试。
2 测试执行过程和结果
2.1 测试对象和测试环境
2.1.1 测试对象
设备云
数据库
缓存
平台web应用
DTU终端设备……
数据收发服务
上传消息队列
消息解析服务
下发消息队列

图一：能耗监控系统业务数据流向图
如上图所示，标红的为此次性能测试的主要测试对象，共有如下四个：
1）能耗监控平台web应用的整体性能（包括缓存和数据库）
2）与设备云交互的数据收发模块（TERMINAL）
3）消息解析服务程序（HANDLE）
4）定时任务（主要是统计分析、下发等定时任务功能）
各测试对象的详细说明如下：
u 能耗监控平台（前台web应用）
能耗监控平台前台应用的主要功能包括实时控制、设备控制、设备管理、统计分析、审计公示、系统管理六大体系组成。由于审计公示和系统管理使用频率非常低，所以不作为此次测试对象。其余的功能模块按优先级由高到低依次递减为：实时监控、统计分析、设备控制、设备管理。在此选取了部分主要业务场景作为测试对象，一共有如下几点：
场景名称
业务场景描述
使用占比
数量级
登录
用户登录系统打开首页
不计
1万用户量
实时监控
用户登录系统，到实时监控页面查看设备实时监控数据。（包含能耗监控、实时抄表、设备状态监控功能）
40%
4万台设备的实时监控数据
统计分析
用户登录系统，查看各项统计分析数据。
30%
4万台设备
设备管理
用户登录系统增删改查设备信息、增删改查建筑物信息。
20%
4万台设备
4万建筑物信息
设备控制
用户登录系统，查看MN策略、定时策略，查看控制日志。
10%
4万台设备
对于web应用主要测试的是平台最大支持在线使用人数，平均响应时间和吞吐量。

u 与设备云交互的数据收发模块（TERMINAL）
处理能耗监控与设备云收发数据的程序是TERMINAL，双方根据设备云接入接口进行交互。设备云获取数据消息为ModBus协议。
服务功能
功能描述分析
使用占比
数量级
接收设备云透传过来的数据
这块功能包括以下几个步骤：
1）设备云下发消息给DTU设备获取监控数据。
2）DTU设备向设备云传输监控数据。
3）设备云存储转发DTU上传给它的数据。
4）TERMINAL接收设备云透传过来的数据并写入消息队列。
从1-4步骤都要测试。
90%
4万台设备的监控数据
下发设备命令数据到终端
这块功能包括以下几个步骤：
1）平台下发指令到消息队列。
2）TERMINAL程序到消息队列去获取下发指令下发到设备云。
3）设备云转发到DTU设备。
只测试1-2步骤。
10%
4万台设备
登录设备云与设备云保持心跳连接
TERMINAL收发数据之前需要登录到设备云，登录后需要定时发送心跳保持激活状态。
忽略不计
每4分钟发一次，每天360次。
针对这块程序主要测试的是程序收发数据的速度。

u 消息解析程序（HANDLE）
该程序是用于从消息队列中获取信息并解析成数据写入缓存和数据库中。是主动从消息队列里取数据进行处理。针对这块程序主要测试程序的处理速度和稳定性。

u 定时任务
定时任务一共有如下7个：
1）检查设备状态
2）清楚数据库表数据
3）Data表统计如Statistics表
4）整点报告
5）MN策略下发
6）定时策略扫描
7）定时策略下发
这块主要测试的是定时任务在大数据量的情况下的执行速度。

2.1.2 网络拓扑结构
能耗监控平台的网络拓扑结构图如下：

图二：能耗监控平台V2系统网络拓扑结构图
各个测试对象对应上图中的部署机器如下：
1）“Patrol”部署的是能耗监控平台web应用（前台）、平台缓存是在“缓存服务器”、平台数据库是在“数据库”服务器上。
2）与设备云交互的数据收发模块（TERMINAL程序）部署在“接口服务器”上。
3）消息解析程序（HANDLE）部署在“数据解析处理服务器”上。消息队列单独部署在“消息队列服务器”上。
由于测试环境机器紧张，所以除了数据库和接口服务器是单独部署在一台机器上，其他应用程序全部部署在一台机器上。测试时会对性能测试结果造成一定影响。

2.1.3 硬件及软件环境
测试环境机器配置：
机型
CPU
内存
硬盘
数量和用途
PC兼容机1
I3
4G
500G
部署应用程序，一共包括：web应用、缓存、消息队列、消息解析程序。CentOS系统
PC兼容机2
I3
2G
500G
部署MySQL数据库：CentOS系统+mysql
PC兼容机3
I3
4G
500G
部署接口程序TERMINAL：
CentOS系统+Tomcat

加压测试机环境：
机型
CPU
内存
硬盘
数量和用途
PC兼容机
I3
4G
500G
2台，用于运行测试工具，对系统加压。
软件环境：win7系统+JDK1.7+Jmeter

2.2 测试策略和方法
针对能耗监控平台（web应用）采用的测试策略如下：
1、首先在数据库中把业务数据量加到标准值后，单次访问各主要页面功能，先确保平台上的各块功能在单次操作下，响应时间不超过3秒。排除明显的性能问题。
2、选取多个典型业务场景，对整个平台进行负载测试。依次加大并发数，直到请求响应报错（包括服务器拒绝、超时、程序报错）或者系统、程序崩溃。由于时间问题，此次不单独针对单个业务场景做测试，如果在测试过程中发现某个业务场景性能可能存在问题，再单独压测。
3、平台稳定性测试，在用户访问峰值压力下，持续访问平台功能，测试平台是否能长时间稳定运行。
预期得到的测试结果指标有：
指标名称
指标说明
限制条件
最优并发数
在一定限制条件下，平台所能承受的最大并发数（严格并发）
在这个并发数下，平均响应时间不超过5秒，系统无报错，服务器系统资源cpu不超过75%，内存不超过75%
最大吞吐量
系统每秒能够处理的最大请求数。
单位：请求数/秒
在这个吞吐量下，平均响应时间不超过5秒，系统无报错，服务器平均系统资源cpu不超过75%，内存不超过75%
平均响应时间
最优并发数下的系统平均响应时间
条件同最优并发数
持续稳定运行时间
在最优并发数下持续运行的时间
持续稳定运行期间系统不报错，不崩溃，系统资源占用稳定。一般不小于1小时。

针对TERMINAL数据收发服务的测试采用如下策略：
1、先测试单次收发数据的处理响应时间，排除明显性能问题。
2、再分别测试数据接收和下发的处理速度。测试数据接收速度的时候，写程序用EDP协议模拟设备云直接上传大量的实时监控数据。发送完后统计全部写入消息队列的时间、验证正确率。测试下发时，先在消息队列中加入大量下发数据，再开启程序发送到设备云，记录消息全部出队列时间，即下发完成耗时。
3、最后测试程序较长时间运行的稳定性。
4、测试过程中需要监控消息队列的处理情况和系统资源占用情况。
预期得到的测试结果指标有：
指标名称
指标说明
限制条件
数据接收处理速度
在一定限制条件下，程序处理消息的速度
（单位：消息数/秒）
在这个处理速度下，消息处理错误率为0，系统无报错，服务器系统资源在处理完成后回落到正常值。
数据下发处理速度
在一定限制条件下，程序下发消息的速度
（单位：消息数/秒）
在这个处理速度下，消息处理错误率为0，系统无报错，服务器系统资源在处理完成后回落到正常值。
持续稳定运行时间
在整体最大处理速度下，程序能持续稳定运行的时间
运行期间系统不报错，不崩溃，系统资源占用稳定（CPU持续值不超过85%，内存持续值不超过85%，且执行完后迅速回落到正常值）。
一般不小于1小时。

针对HANDLE数据处理服务程序的测试采用如下策略：
模拟真实场景准备大量各种业务数据消息进入消息队列，开启消息处理程序执行解析入库操作，执行完后记录处理时间，校验处理结果的正确性。
预期得到的测试结果指标有：消息处理速度XX条/秒和最小持续稳定运行时间。
针对定时任务的测试策略和方法如下：
在测试数据库中加入一定量的真实业务数据，然后开启各个定时任务执行，记录定时任务的执行时间和资源消耗情况，校验处理结果的正确性。
预期得到的测试结果指标有：每个定时任务的执行耗时。

2.3 测试工具及程序
本次性能测试要使用到的测试工具和用途如下：
工具名称
工具用途
工具版本
是否需培训
Jmeter
用于测试能耗监控平台性能
V2.13
否
FireBug
用于排查网页性能
V2.0.8
否
本次能耗监控平台测试使用开源性能测试工具Jmeter V2.13模拟用户发送请求访问平台，通过Jmeter线程组控制生成虚拟用户数，对被测系统进行负载测试。如果在测试web应用过程中发现某些页面单次访问加载时间很慢则采用FireBug工具进行排查。对于Linux系统的服务器使用Jmeter自带的监控插件来监控。
本次性能测试要使用到的测试程序及其功能定义如下：
程序名称
程序主要实现功能
程序开发语言
使用说明
feinno_onenet_emulator
模拟DTU设备向设备云上传监控数据
JAVA
启动后每隔5分钟发送4.6万条消息到terminal程序

2.4 系统资源监控及关注指标
每次压力测试结果数据由测试工具Jmeter自带的监听器搜集成聚合报告。
Jmeter聚合报告需关注的参数和指标如下：
指标名称
性能参数
说明
正常范围值
平均响应时间
average
指单次测试总请求数的平均响应时间。
小于3-5秒
中间时间
median
中位数，也就是 50 ％ 用户的响应时间
小于3秒
90%用户响应时间
90%_line
90 ％ 用户的响应时间
小于5秒
最大响应时间
max
单次测试中最大的响应时间
小于5秒
事务错误率
error%
本次测试中错误的请求数/请求总数
等于0%
吞吐量
Throughput
表示每秒完成的请求数
越大越好
每秒数据量
KB/Sec
每秒从服务器端接收到的数据量
略小于带宽

Linux服务器资源占用监控工具选用Jmeter自带的监控插件来监控，具体需要监控的服务器指标有：
指标名称
说明
正常范围值
CPU使用率（%CPU）
程序的cpu的使用率
不超过80%
内存内存使用率（%MEM）
程序的内存使用率
不超过75%
平均负载（Lord Average）
过去1分钟、5分钟、15分钟内运行进程队列中的平均进程数量。
不超过5

对于数据库需要监控的指标有数据库连接数、SQL执行时间、监控执行太慢的SQL。对于Tomcat web服务器需要监控的有：当前连接请求数、log日志。

2.5 测试结果
2.5.1 能耗监控平台
2.5.1.1测试结果
根据测试方案既定的测试策略和方法，测试出能耗监控平台（web应用）性能情况如下。
u 主要业务功能的单次响应时间
能耗监控平台主要页面单次访问耗时测试
前置条件
业务数据已准备完毕：1万用户数据、1万企业、4万设备。
使用工具
FireBUG：用于页面加载耗时分析
Jmeter：用于测试服务器端响应时间
页面/功能名称
服务器响应时间
页面加载总耗时
用户登录
73ms
3.6秒
打开实时抄表页面
486ms
2.6秒
实时抄表功能
212ms
661ms
实时告警页面
260ms
9.25秒
设备状态监控页面
271ms
2.03秒
运行状态报告页面
12ms
830ms
分类能耗报表页面
75ms
1.03秒
打开设备能耗分析页
292ms
2.1秒
设备能耗分析
41ms
1.66秒
能耗TOP
217ms
947ms
打开能耗成本预估页面
147ms
263ms
能耗成本预估
71ms
283ms
设备统计报表
319ms
1.12秒
打开节能效果分析页面
260ms
260ms
节能效果分析
82ms
387ms
打开设备维护页面
35ms
561ms
打开向导新增设备页面
140ms
315ms
打开设备编辑页面
23ms
23ms
打开建筑物维护页面
35ms
629ms
打开建筑物添加页面
175ms
1.29秒
建筑物维护-新增
115ms
729ms
打开建筑物修改页面
68ms
979ms
建筑物维护-修改功能
133ms
836ms
建筑物关联设备
56ms
790ms
策略控制页面
20ms
20ms
MN策略维护页面
144ms
865ms
定时策略维护页面
77ms
1.17秒
测试结果
测试通过（平台的主要功能页面无单次访问响应特别慢的功能）
测试通过标准

1）每个页面功能单次访问加载总耗时不超过10秒。
2）服务器响应时间不超过3秒。
备注说明

1）页面加载总耗时是指：浏览器首次发送请求到页面完全加载出来的时间。
2）服务器响应时间是指：发送请求到服务器端，服务器端返回的时间，不算客户端加载呈现时间。

u 平台整体负载测试
能耗监控平台整体负载测试
测试目的
测试平台能承受的最大访问峰值
并发用户数
平均响应时间
吞吐量
错误率
系统资源占用
测试结果
100
960ms
50
0
应用：cpu10%，内存30%
数据库：cpu75%，内存20%
通过
200
2157ms
62
0
应用：cpu35%，内存30%
数据库：cpu80%，内存20%
通过
500
6848ms
59
0
应用：cpu20%，内存35%
数据库：cpu100%，内存40%
通过
600
8569ms
59
0
应用：cpu20%，内存35%
数据库：cpu100%，内存40%
通过
700
8662ms
52
0.37%
应用：cpu20%，内存35%
数据库：cpu100%，内存40%
失败
800
9715ms
68
3.7%
应用：cpu10%，内存40%
数据库：cpu100%，内存45%
失败
测试结论
1）在tomcat和数据库均为单机的环境下，平台最多能支持600个用户并发访问。
2）平台最大吞吐量为62个请求每秒（200个并发用户时）
备注说明
700和800并发下所有报错为建立连接超时错误，说明tomcat服务器已到达极限。

u 平台整体稳定性测试
能耗监控平台整体稳定性测试
测试目的
测试平台在最大访问峰值的情况下是否能够稳定运行
并发用户数和持续时间
平均响应时间
吞吐量
错误率
系统资源占用
测试结果
600-1小时
7716ms
56
0
应用：cpu10%，内存40%
数据库：cpu95%，内存50%
通过
600-2小时
14302ms
35
0
应用：cpu10%，内存65%
数据库：cpu100%，内存90%
通过
测试结论
平台在峰值600个并发用户持续访问的情况下，至少能持续稳定正常运行2个小时。
备注说明
并发600个用户持续加压时，手动访问平台大部分功能较流畅，稍有卡顿但还能接收。

2.5.1.2发现的问题
问题编号
问题描述
当前状态
1-1
持续运行加数据脚本后java堆内存溢出。
已修复
1-2
加压并发100时报错tomcat线程被占满。
已修复
1-3
查询类功能加压并发到200，数据库cpu一直保持100%。
已修复
1-4
并发500访问时报错，数据库连接池连接数不够用。
已修复
1-5
并发500访问时，部分程序功能报404错误。
已修复

以上各问题处理详情如下：
【问题1-1】持续运行加数据脚本后报错java.lang.OutOfMemoryError: PermGen space
问题原因：JAVA堆PermGen space内存溢出。
解决方案：加内存，手动设置MaxPermSize大小修改TOMCAT_HOME/bin/catalina.sh
在“echo"Using CATALINA_BASE: $CATALINA_BASE"”
上面加入： JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m

【问题1-2】加压并发100时报错INFO: Maximum number of threads (200) created for connector with address null and port 8091
问题原因：没有配置Tomcat程序池
解决方案：已加上Tomcat程序池，最大线程设置为500

【问题1-3】查询类功能加压并发到200，数据库cpu一直保持100%，数据库资源占用大，平均响应时间长，tomcat线程大多数处于等待中。
问题原因：数据库没有加索引、部分SQL执行耗时较长（有问题的SQL见附录）。
解决方案：添加数据库索引，优化SQL，已完成优化。

【问题1-4】并发500的时候，响应时间太长，程序报错：nested exception is org.hibernate.exception.GenericJDBCException: Could not open connection
com.alibaba.druid.pool.GetConnectionTimeoutException: loopWaitCount 1, wait millis 60000
问题原因：数据库连接数太少，只有32个。连接池溢出导致的等待时间过长所以响应太慢。
解决方案：修改数据库连接池配置，增大连接数至500。

【问题1-5】并发500的时候，部分功能出现404错误。
问题原因：不详
解决方案：优化了SQL增大了数据库连接池后，该问题没有再复现。

2.5.2 数据收发模块（Terminal）
测试与设备云交互的数据收发模块分为两部分：一部分是数据接收、另一部分是数据下发。主要测试程序收发数据的速度。
2.5.2.1测试结果
u 测试数据上传下发消息
数据上传下发测试
测试目的
测试程序处理数据接收下发的速度。
上传/下发
处理消息总量
总耗时
错误率
系统资源占用
测试结果
上传消息
29459
5秒
0
应用：cpu45%，内存6.2%
通过
46363
8秒
0
应用：cpu50%，内存8%
通过
7541626
8小时
0
应用：cpu50.0%，内存10.2%
通过
下发消息
35101
80秒
0
应用：cpu5%，内存6%
通过
31万
9分钟
0
应用：cpu6.4%，内存9.4%
通过
持续两天，每分钟3万数据
80秒/次
0
应用：cpu8%，内存10%
通过
测试结论
Terminal程序接收上传数据速度为：5892条/秒
Terminal程序处理下发数据速度为：439条/秒
备注说明
1）假设有10万台设备，每台设备5条数据流，则完成一次采集数据50万上传的时间是85秒，可以满足业务需求。
2）每天凌晨设备指令下发是10万，全部下发完毕是3.7分钟，也满足业务需求。

2.5.2.2发现的问题
暂无
2.5.3 消息解析程序（Handle）
2.5.3.1测试结果
消息解析程序测试
测试目的
测试消息解析程序的处理速度
消息总数
总耗时
平均入库速度
是否全部入库
系统资源占用
测试结果
46363
1.5分钟
30908条/分钟
是
应用：cpu45%，内存30%
数据库：cpu35%，内存88%
队列/缓存：cpu10%，内存10%
通过
324541
10分钟
32454条/分钟
是
应用：cpu57%，内存30.7%
数据库：cpu35%，内存88%
队列/缓存：cpu10.8%，内存10%
通过
1715431
48分钟
35738条/分钟
是
应用：cpu60%，内存30%
数据库：cpu36.5%，内存87.7%
队列/缓存：cpu11.2%，内存8%
通过
1019986（每次处理46363条，共处理22次）
6小时
30908条/分钟
是，无数据积压
应用：cpu52%，内存30.3%
数据库：cpu33%，内存89%
队列/缓存：cpu11%，内存9%
通过
测试结论
Handle程序处理数据平均3万条/分钟。若以5分钟作为每台设备的采集周期，每台设备1个数据流，则可支撑15万台设备，已达到业务要求。该程序能在数据量大时，持续不间断正确处理数据至少1小时左右。能稳定支持数据采集处理。

3.5.3.2发现的问题
问题编号
问题描述
当前状态
3-1
Handle程序处理数据入库速度太慢（速度30条/秒）。
已修复
3-2
Handle程序处理数据入库有数据遗漏。
已修复
3-3
Handle程序线程池占满后报错，程序崩溃无法继续运行。
已修复
以上各问题处理详情如下：
【问题3-1】Handle程序处理数据入库速度太慢（速度30条/秒）。
问题原因：程序采用单线程处理，且每条数据入库都要去打开连接写数据库。
解决方案：程序采用多线程处理。

【问题3-2】Handle程序处理数据入库有数据遗漏（68246条数据少入库50条）。
问题原因：程序采用多线程处理后数据有遗漏。
解决方案：修改程序处理。

【问题3-3】Handle程序线程池占满后报错，程序崩溃无法继续运行。com.feinno.energy.utils.thread.SimpleThreadPool - The work queue is full!
java.util.concurrent.RejectedExecutionException: null
问题原因：程序问题。
解决方案：修改程序处理。

2.5.4 定时任务
2.5.4.1测试结果
定时任务主要测试任务执行时间，详细测试结果见下表：
定时任务名称
执行频率
数据量
执行耗时
程序是否报错
测试结果
检查设备状态
每30分钟一次
47604
1秒
否
通过
清除数据库表数据
每天3:05执行
6个表的数据
1秒内
否
通过
Data表统计入Statistics表
每天2:05执行
91万数据
86秒
否
通过
整点报告
每1小时执行一次
10002
142秒
否
通过
MN策略下发
每天00:05执行
35101
21秒
否
通过
定时策略扫描
每10分钟一次
35101
1秒内
否
通过
定时策略下发
不定时
150
9秒
否
通过
系统资源占用
没任务执行时：
应用cpu占用0.7%,内存占用4.1%；数据库cpu0.7%，21.5%
有多个任务同时执行时：
应用cpu占用50%,内存占用10%；数据库cpu25%，58%
测试结论
按照4万设备的业务量来算，所有定时任务的执行速度都能够满足业务需求。

2.5.4.2发现的问题
问题编号
问题描述
当前状态
4-1
整点报告任务执行时报错（邮箱无法使用）。
已修复
4-2
整点报告任务执行时报错（时间格式问题）。
已修复
4-3
测试定时策略扫描任务时，有一个容错问题，程序读脏数据报错。
已修复
4-4
检查设备状态定时任务运行时报错。
已修复
4-5
检查设备状态时，正常设备和数据流的状态被标为异常。
已修复

以上各问题处理详情如下：
【问题4-1】整点报告任务执行时报错：javax.mail.MessagingException: Unknown SMTP host: ;
问题原因：因为整点报告下发邮件使用的是开发人员的私人163邮箱，频繁发邮件的话会被当成垃圾邮箱禁用，禁用后程序会报错。
解决方案：加内存重新申请个企业邮箱进行替换（截止发报告时，仍未申请到邮箱进行替换）

【问题4-2】整点报告任务执行时报错：
java.lang.NumberFormatException: For input string: "20015E.20015E44"
问题原因：程序代码问题
解决方案：修改程序解决

【问题4-3】测试定时策略扫描任务时，报错：
java.text.ParseException: Unparseable date: "2015-06-16 null"）
问题原因：容错问题，程序读脏数据报错
解决方案：修改程序解决

【问题4-4】检查设备状态定时任务运行时报错。com.feinno.energy.quartz.task.CheckDeviceTaskScheduler - 检查设备任务失败java.lang.NullPointerException: null
问题原因：程序问题
解决方案：修改程序解决

【问题4-5】检查设备状态时，正常设备和数据流的状态被标为异常。
问题原因：程序问题
解决方案：修改程序解决

3 测试结论指标
能耗监控项目性能测试结果
能耗监控平台性能情况
1、能耗监控平台单机最大可支持600人同时在线访问，平均响应时间小于9秒。
2、能耗监控平台在600人并发访问峰值时，可至少持续2小时以上稳定运行，应用服务器资源占用保持在cpu低于30%，内存低于40%；数据库服务器资源占用cpu 96%，内存50%。
与设备云交互的数据处理程序（TERMINAL）性能情况
1、接收完3万条设备云上传的消息总耗时5秒，平均6000条/秒。
2、单纯处理完下行消息队列中的3万条消息共耗时80秒，平均375条/秒。
3、在同时不间断处理上传下发消息的情况下，至少可持续运行24小时，无丢包无异常，服务器资源占用保持在安全范围内。
消息解析程序（HANDLE）和定时任务性能情况
1、Handle程序处理完4.6万消息量总耗时1.5分钟，平均3万条/秒入库。
2、检查设备定时任务执行耗时1秒。
3、凌晨清楚数据库表数据任务执行1秒内完成。
4、当日能耗统计任务执行138万数据耗时103秒。
5、整点报告定时任务执行耗时142秒。
6、MN策略下发（35101条数据）定时任务执行耗时21秒。
7、定时策略定点扫描任务耗时1秒内。
8、定时策略下发（164条数据）定时任务执行耗时9秒。
测试结果数据整体分析
根据能耗监控系统的架构结合以上性能数据，对系统有10万台设备接入后的性能进行如下分析：
1、10万台设备采集数据同时上传经过terminal程序进入队列的时间大约20秒，进入队列后handle程序全部处理入库的耗时大约是3分钟，设备采集周期为5分钟，故不会产生数据积压延迟，满足业务要求。若以5分钟作为每台设备的采集周期，每台设备1个数据流，则最大可支撑15万台设备同时采集数据。
2、假设10万台设备大约来自于1000个用户（每个100台），目前系统单机满足访问峰值为600，根据平均用户并发数计算公式C=nL/T来计算（n是每天登录用户数，L是每个用户每天使用系统的时长预测为1小时，T是系统每天有用户使用的时间段预测为8小时），则系统每天可以支持4800个用户访问，能够满足业务需求。且以上结果只是单机性能，如进行横向扩展，则每增加一台机器预测可以支持的用户量增加80%。
3、系统的后台定时任务大多设置在凌晨执行，且在业务量级为4万台设备时，执行速度仍保持在秒的级别，且资源占用率较低。故此模块不存在性能瓶颈，不会对整体性能造成影响。
结论概述
通过上述分析可得出以下结论：
1、能耗监控系统V2.0能够满足10万台终端设备接入，最大能够满足15万台终端设备接入（注意：此处假设每台设备1个数据流，如设备数据流增加则设备数对应成倍减少，例如每台设备5个数据流，则最大设备支持数为3万）。
2、能耗监控平台单机最大可支持600人并发访问操作，每天可支持4800人登录访问（推算值）。

系统整体性能效果请参见下方演示图：

图三：能耗监控平台V2系统整体性能情况演示图

测试结论：能耗监控平台V2.0满足预期设计的性能需求，测试通过。

4 测试总结
此次性能测试共发现12个问题，问题统计如下：
Ø 中间件/程序配置问题：3个
Ø 数据库/SQL问题：1个（包括多个SQL优化和索引优化）
Ø 程序代码问题：6个
Ø 其他：2个
根据以上问题有如下优化建议供项目组参考，以避免后续发生类似问题：
1、希望以后在规划系统性能时就考虑好相关服务器的优化配置参数。
2、数据库SQL编写要加强，避免编写出执行效率低下的SQL。数据库设计时就要把索引规划好。加强数据库批量入库技术性能研究、总结推广。
3、程序容错性有待加强。
5 附录
附录1：此次性能测试的测试用例执行结果
附录2： 此次性能测试发现的问题报错文件
附录3：此次性能测试的测试脚本和测试程序