物联网能耗监控项目性能测试报告V0全解

1、文档编号NH_XN_01文档类别测试文档文档级别高中移动物联网能耗监控平台V2.0性能测试报告文档，修订记录版本日期版本描述作者检查人/日期备注2015.06.291.0创建文档唐晓文部门管理体系文件-能耗监控项目性能测试报告V1.0目录 TOC o 1-5 h z HYPERLINK l bookmark3 o Current Document 测试概述 4 HYPERLINK l bookmark5 o Current Document 项目背景 4 HYPERLINK l bookmark7 o Current Document 测试目的 4 HYPERLINK l bookmark9

2、o Current Document 术语、定义和缩略语 4 HYPERLINK l bookmark11 o Current Document 测试内容和范围 5 HYPERLINK l bookmark13 o Current Document 测试执行过程和结果 5 HYPERLINK l bookmark15 o Current Document 测试对象和测试环境 5 HYPERLINK l bookmark17 o Current Document 测试对象 5 HYPERLINK l bookmark19 o Current Document 网络拓扑结构 8 HYPERLINK

3、 l bookmark21 o Current Document 硬件及软件环境 9 HYPERLINK l bookmark23 o Current Document 测试策略和方法 10 HYPERLINK l bookmark25 o Current Document 测试工具及程序 12 HYPERLINK l bookmark27 o Current Document 系统资源监控及关注指标 12 HYPERLINK l bookmark29 o Current Document 测试结果 13 HYPERLINK l bookmark31 o Current Document 能耗

4、监控平台 13与设备云交互的数据收发模块 17消息解析程序 18 HYPERLINK l bookmark51 o Current Document 定时任务 20 HYPERLINK l bookmark57 o Current Document 测试结论指标 22 HYPERLINK l bookmark59 o Current Document 测试总结 25 HYPERLINK l bookmark61 o Current Document 附录 251测试概述项目背景能耗监控平台将主要从能耗分析、预估及对应节能策略入手，主要完成对能源终端的 监控、管理、分析、预估，并根据以上数据进行

5、对应节能策略配置的管理系统。平台主要 功能详见能耗监控平台V2.0需求规格说明书。测试目的此次性能测试的目的是：通过在测试环境中，运用性能测试策略和测试工具对能 耗监控平台的关键节点进行性能测试，最终得出各系统节点的性能情况指标数据，以 此来对整个能耗监控系统性能做出评估。术语、定义和缩略语名称解释能耗监控系统能耗监测系统是指通过对能耗设备和能耗建筑安装分类 和分项能耗计量装置，采用物联网等技术手段及时采集 能耗数据，实现重点建筑、设备能耗的在线监测和动态 分析功能的硬件系统和软件系统的统称。中移动物联网设备云平台中移设备云平台是指中移物联网有限公司自主研发的开 放、共赢OneNET平台，为各

6、种跨平台物联网应用、行业 解决方案，提供简便的云端接入、存储、计算和展现。响应时间请求从发送开始到接收完服务器响应结果的时间吞吐量系统最大的每秒处理请求量，单位是：请求/秒部门管理体系文件-能耗监控项目性能测试报告V1.0测试内容和范围此次性能测试的内容和范围是整个能耗监控系统，从采集数据开始到能耗监控 平台展现数据、维护设备、统计报表。能耗监控平台又分为前后台，由于后台使用 频率较小，故不纳入此次性能测试范围。由于整个业务流程需要和设备云交互，虽 然设备云不在此次测试范围内，但也需要模拟设备云向设备发起获取数据请求，测 试整体业务性能。如发现由设备云引起的性能问题则推动外部解决，不作为此次测

7、 试的重点。此次只针对于能耗监控系统自身开发的功能或接口服务程序进行测试。2测试执行过程和结果测试对象和测试环境测试对象图一：能耗监控系统业务数据流向图上传消息队列下发消息队列ruDT终端设备平台web应用消息解析服务数据库如上图所示，标红的为此次性能测试的主要测试对象，共有如下四个：1）能耗监控平台web应用的整体性能（包括缓存和数据库）2）与设备云交互的数据收发模块（TERMINAL）3）消息解析服务程序（HANDLE）部门管理体系文件-能耗监控项目性能测试报告V1.04）定时任务（主要是统计分析、下发等定时任务功能） 各测试对象的详细说明如下： 能耗监控平台（前台web应用）能耗监控平台

8、前台应用的主要功能包括实时控制、设备控制、设备管理、统计分 析、审计公示、系统管理六大体系组成。由于审计公示和系统管理使用频率非常低， 所以不作为此次测试对象。其余的功能模块按优先级由高到低依次递减为：实时监控、 统计分析、设备控制、设备管理。在此选取了部分主要业务场景作为测试对象，一共 有如下几点：场景名称业务场景描述使用占比数量级登录用户登录系统打开首页不计1万用户量实时监控用户登录系统，到实时监控页面查看设备实时监控数据。（包含能耗监控、实时抄表、设备状态监控功能）40%4万台设备的实时监控数据统计分析用户登录系统，查看各项统计分析数据。30%4万台设备设备管理用户登录系统增删改查设备信

9、息、增删改查建筑物信息。20%4万台设备4万建筑物信息设备控制用户登录系统，查看MN策略、定时策略，查看控制日志。10%4万台设备对于web应用主要测试的是平台最大支持在线使用人数，平均响应时间和吞吐量。与设备云交互的数据收发模块（TERMINAL）处理能耗监控与设备云收发数据的程序是TERMINAL,双方根据设备云接入接口 进行交互。设备云获取数据消息为ModBus协议。服务功能功能描述分析使用占比数量级接收设备云透传过来的数据这块功能包括以下几个步骤：1）设备云下发消息给DTU设备获取监控数据。2）DTU设备向设备云传输监控数据。3）设备云存储转发DTU上传给它的数据。90%4万台设备的监

10、控数据4）TERMINAL接收设备云透传过来的数据并写入消息队列。从1-4步骤都要测试。下发设备命令数据到终端这块功能包括以下几个步骤：1）平台下发指令到消息队列。2）TERMINAL程序到消息队列去获取下发指令下发到设备云。3）设备云转发到DTU设备。只测试1-2步骤。10%4万台设备登录设备云与设备云保持心跳连接TERMINAL收发数据之前需要登录到设备云，登录后需要定时发送心跳保持激活状态。忽略不计每4分钟发一 次，每天360 次。针对这块程序主要测试的是程序收发数据的速度。消息解析程序（HANDLE）该程序是用于从消息队列中获取信息并解析成数据写入缓存和数据库中。是主动 从消息队列里取

11、数据进行处理。针对这块程序主要测试程序的处理速度和稳定 性。定时任务定时任务一共有如下7个：1）检查设备状态2）清楚数据库表数据3）Data表统计如Statistics表4）整点报告5）MN策略下发6）定时策略扫描7）定时策略下发这块主要测试的是定时任务在大数据量的情况下的执行速度。2.1.2 网络拓扑结构能耗监控平台的网络拓扑结构图如下：智能设备DTU设备图二：能耗监控平台V2系统网络拓扑结构图各个测试对象对应上图中的部署机器如下：部门管理体系文件-能耗监控项目性能测试报告V1.01） “Patrol”部署的是能耗监控平台web应用（前台）、平台缓存是在“缓存服 务器”、平台数据库是在“数据

12、库”服务器上。2）与设备云交互的数据收发模块（TERMINAL程序）部署在“接口服务器”上。3）消息解析程序（HANDLE）部署在“数据解析处理服务器”上。消息队列单独 部署在“消息队列服务器”上。由于测试环境机器紧张，所以除了数据库和接口服务器是单独部署在一台机器 上，其他应用程序全部部署在一台机器上。测试时会对性能测试结果造成一定影响。2.1.3 硬件及软件环境测试环境机器配置：机型CPU内存硬盘数量和用途PC兼容机1I34G500G部署应用程序，一共包括：web应用、缓存、消息队列、消息解析程序。CentOS系统PC兼容机2I32G500G部署MySQL数据库：CentOS系统+mysq

13、lPC兼容机3I34G500G部署接口程序TERMINAL:CentOS 系统+Tomcat加压测试机环境：机型CPU内存硬盘数量和用途PC兼容机I34G500G2台，用于运行测试工具，对系统加压。软件环境：win7 系统+JDK1.7+Jmeter部门管理体系文件-能耗监控项目性能测试报告V1.0测试策略和方法针对能耗监控平台（web应用）采用的测试策略如下：1、首先在数据库中把业务数据量加到标准值后，单次访问各主要页面功能，先确保 平台上的各块功能在单次操作下，响应时间不超过3秒。排除明显的性能问题。2、选取多个典型业务场景，对整个平台进行负载测试。依次加大并发数，直到请求 响应报错（包括

14、服务器拒绝、超时、程序报错）或者系统、程序崩溃。由于时间问题， 此次不单独针对单个业务场景做测试，如果在测试过程中发现某个业务场景性能可能 存在问题，再单独压测。3、平台稳定性测试，在用户访问峰值压力下，持续访问平台功能，测试平台是否能 长时间稳定运行。预期得到的测试结果指标有：指标名称指标说明限制条件最优并发数在一定限制条件下，平台所能承受的最大并发数（严格并发）在这个并发数下，平均响应时间不超过5秒，系统无报错，服务器系统资源cpu不超过75%，内存不超过75%最大吞吐量系统每秒能够处理的最大请求数。单位：请求数/秒在这个吞吐量下，平均响应时间不超过5秒，系统无报错，服务器平均系统资源cp

15、u不超过75%，内存不超过75%平均响应时间最优并发数下的系统平均响应时间条件同最优并发数持续稳定运行时间在最优并发数下持续运行的时间持续稳定运行期间系统不报错，不 崩溃，系统资源占用稳定。一般不 小于1小时。针对TERMINAL数据收发服务的测试采用如下策略：1、先测试单次收发数据的处理响应时间，排除明显性能问题。部门管理体系文件-能耗监控项目性能测试报告V1.02、再分别测试数据接收和下发的处理速度。测试数据接收速度的时候，写程序用EDP 协议模拟设备云直接上传大量的实时监控数据。发送完后统计全部写入消息队列的时 间、验证正确率。测试下发时，先在消息队列中加入大量下发数据，再开启程序发送到

16、设 备云，记录消息全部出队列时间，即下发完成耗时。3、最后测试程序较长时间运行的稳定性。4、测试过程中需要监控消息队列的处理情况和系统资源占用情况。预期得到的测试结果指标有：指标名称指标说明限制条件数据接收处理速度在一定限制条件下，程序处理消息的速度（单位：消息数/秒）在这个处理速度下，消息处理错误率为0，系统无报错，服务器系统资源在处理完成后回落到正常值。数据下发处理速度在一定限制条件下，程序下发消息的速度（单位：消息数/秒）在这个处理速度下，消息处理错误率为0，系统无报错，服务器系统资源在处理完成后回落到正常值。持续稳定运行时间在整体最大处理速度下，程序能持续稳定运行的时间运行期间系统不报

17、错，不崩溃，系 统资源占用稳定（CPU持续值不超过 85%，内存持续值不超过85%，且执 行完后迅速回落到正常值）。一般不小于1小时。针对HANDLE数据处理服务程序的测试采用如下策略：模拟真实场景准备大量各种业务数据消息进入消息队列，开启消息处理程序执行 解析入库操作，执行完后记录处理时间，校验处理结果的正确性。预期得到的测试结果指标有：消息处理速度XX条/秒和最小持续稳定运行时间。针对定时任务的测试策略和方法如下：在测试数据库中加入一定量的真实业务数据，然后开启各个定时任务执行，记录定时 任务的执行时间和资源消耗情况，校验处理结果的正确性。预期得到的测试结果指标有：每个定时任务的执行耗时。

18、部门管理体系文件-能耗监控项目性能测试报告V1.0测试工具及程序本次性能测试要使用到的测试工具和用途如下：工具名称工具用途工具版本是否需培训Jmeter用于测试能耗监控平台性能V2.13否FireBug用于排查网页性能V2.0.8否本次能耗监控平台测试使用开源性能测试工具Jmeter V2.13模拟用户发送请求访 问平台，通过Jmeter线程组控制生成虚拟用户数，对被测系统进行负载测试。如果在 测试web应用过程中发现某些页面单次访问加载时间很慢则采用FireBug工具进行排 查。对于Linux系统的服务器使用）1土6自带的监控插件来监控。本次性能测试要使用到的测试程序及其功能定义如下：程序名

19、称程序主要实现功能程序开发语言使用说明feinno_onenet_emulator模拟DTU设备向设备云上传监控数据JAVA启动后每隔5分钟发送4.6万条消息到terminal程序系统资源监控及关注指标每次压力测试结果数据由测试工具Jmeter自带的监听器搜集成聚合报告。Jmeter聚合报告需关注的参数和指标如下：指标名称性能参数说明正常范围值平均响应时间average指单次测试总请求数的平均响应时间。小于3-5秒中间时间median中位数，也就是50 %用户的响应时间小于3秒90%用户响应时间90%_line90 %用户的响应时间小于5秒最大响应时间max单次测试中最大的响应时间小于5秒事务

20、错误率error%本次测试中错误的请求数/请求总数等于0%吞吐量Throughput表示每秒完成的请求数越大越好每秒数据量KB/Sec每秒从服务器端接收到的数据量略小于带宽Linux服务器资源占用监控工具选用Jmeter自带的监控插件来监控，具体需要监控的服务器指标有：指标名称说明正常范围值CPU使用率（CPU）程序的cpu的使用率不超过80%内存内存使用率（MEM ）程序的内存使用率不超过75%平均负载(Lord Average )过去1分钟、5分钟、15分钟内运行进程队列中 的平均进程数量。不超过5对于数据库需要监控的指标有数据库连接数、SQL执行时间、监控执行太慢的SQL。对于Tomca

21、t web服务器需要监控的有：当前连接请求数、1窈日志。测试结果能耗监控平台测试结果根据测试方案既定的测试策略和方法，测试出能耗监控平台（web应用）性能情 况如下。主要业务功能的单次响应时间能耗监控平台主要页面单次访问耗时测试前置条件业务数据已准备完毕：1万用户数据、1万企业、4万设备。使用工具FireBUG：页面加载耗时分析设备能耗分析41ms1.66 秒能耗TOP217ms947ms打开能耗成本预估页面147ms263ms能耗成本预估71ms283ms设备统计报表319ms1.12 秒打开节能效果分析页面260ms260ms节能效果分析82ms387ms打开设备维护页面35ms561ms

22、打开向导新增设备页面140ms315ms打开设备编辑页面23ms23ms打开建筑物维护页面35ms629ms打开建筑物添加页面175ms1.29 秒建筑物维护-新增115ms729ms打开建筑物修改页面68ms979ms建筑物维护-修改功能133ms836ms建筑物关联设备56ms790ms策略控制页面20ms20msMN策略维护页面144ms865ms定时策略维护页面77ms1.17 秒测试结果测试通过（平台的主要功能页面无单次访问响应特别慢的功能）测试通过标准1）每个页面功能单次访问加载总耗时不超过10秒。2）服务器响应时间不超过3秒。备注说明1）页面加载总耗时是指：浏览器首次发送请求到页

23、面完全加载出 来的时间。2）服务器响应时间是指：发送请求到服务器端，服务器端返回的 时间，不算客户端加载呈现时间。平台整体负载测试能耗监控平台整体负载测试测试目的测试平台能承受的最大访问峰值并发用户数平均响应时间吞1吐量错误率系统资源占用测试结果100960ms500应用：cpu10%，内存30%数据库：cpu75%，内存20%通过2002157ms620应用：cpu35%，内存30%数据库：cpu80%，内存20%通过5006848ms590应用：cpu20%，内存35%数据库：cpu100%，内存40%通过6008569ms590应用：cpu20%，内存35%数据库：cpu100%，内存4

24、0%通过7008662ms520.37%应用：cpu20%，内存35%数据库：cpu100%，内存40%失败8009715ms683.7%应用：cpu10%，内存40%数据库：cpu100%，内存45%失败测试结论1 ）在tomcat和数据库均为单机的环境下，平台最多能支持600个用户并发访问。2 ）平台最大吞吐量为62个请求每秒（200个并发用户时）备注说明700和800并发下所有报错为建立连接超时错误，说明tomcat服务器已到达极限。平台整体稳定性测试能耗监控平台整体稳定性测试测试目的测试平台在最大访问峰值的情况下是否能够稳定运行并发用户数 和持续时间平均响应时间吞1吐量错误率系统资源占

25、用测试结果600-1小时7716ms560应用：cpu10%，内存40%数据库：cpu95%，内存50%通过600-2小时14302ms350应用：cpu10%，内存65%数据库：cpu100%，内存90%通过测试结论平台在峰值600个并发用户持续访问的情况下，至少能持续稳定正常运行2个小时。备注说明并发600个用户持续加压时，手动访问平台大部分功能较流畅，稍有卡顿但还能接收。发现的问题问题编号问题描述当前状态1-1持续运行加数据脚本后java堆内存溢出。已修复1-2加压并发100时报错tomcat线程被占满。已修复1-3查询类功能加压并发到200，数据库cpu 一直保持100%。已修复1-4

26、并发500访问时报错，数据库连接池连接数不够用。已修复1-5并发500访问时，部分程序功能报404错误。已修复部门管理体系文件-能耗监控项目性能测试报告V1.0以上各问题处理详情如下：【问题1-1】持续运行加数据脚本后报错java.lang.OutOfMemoryError: PermGen space问题原因：JAVA堆PermGen space内存溢出。解决方案：加内存，手动设置MaxPermSize大小修改TOMCAT_HOME/bin/catalina.sh在 “echoUsing CATALINA_BASE: $CATALINA_BASE ”上面加入：JAVA_OPTS=-serve

27、r -XX:PermSize=64M -XX:MaxPermSize=128m【问题 1-2】加压并发 100时报错INFO: Maximum number of threads (200) created forconnector with address null and port 8091问题原因：没有配置Tomcat程序池解决方案：已加上Tomcat程序池，最大线程设置为500【问题1-3】查询类功能加压并发到200，数据库cpu一直保持100%，数据库资源占用大，平均响应时间长，tomcat线程大多数处于等待中。问题原因：数据库没有加索引、部分SQL执行耗时较长(有问题的SQL见附录

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

29、【问题1-5】并发500的时候，部分功能出现404错误。问题原因：不详解决方案：优化了 SQL增大了数据库连接池后，该问题没有再复现。数据收发模块（Terminal）测试与设备云交互的数据收发模块分为两部分：一部分是数据接收、另一部分是 数据下发。主要测试程序收发数据的速度。测试结果测试数据上传下发消息数据上传下发测试测试目的测试程序处理数据接收下发的速度。上传/下发处理消息总量总耗时错误率系统资源占用测试结果上传消息294595秒0应用：cpu45%，内存6.2%通过463638秒0应用：cpu50%，内存8%通过75416268小时0应用：cpu50.0%，内存 10.2%通过下发消息35

30、10180秒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分钟，也满足业务需求。发现的问题暂无消息解析程序（Handle）测试结果消息解析程序测试测试目的测试消息解析程序的处理速度消息总数总耗时平均入库速度是

31、否全部入库系统资源占用测试结果463631.5分钟30908条/分钟是应用：cpu45%，内存30% 数据库：cpu35%，内存88% 队列/缓存：cpu10%，内存10%通过32454110分钟32454条/分钟是应用：cpu57%，内存 30.7% 数据库：cpu35%，内存88% 队歹旷缓存:cpu10.8%，内存10%通过171543148分钟35738条/分钟是应用：cpu60%，内存30% 数据库：cpu36.5% ,内存87.7% 队列/缓存：cpu11.2% ,内存8%通过1019986 （每次处理46363 条，共处 理22次）6小时30908条/分钟是，无数据积压应用：cp

32、u52%，内存 30.3% 数据库：cpu33%，内存89% 队列/缓存：cpu11%，内存9%通过测试结论Handle程序处理数据平均3万条/分钟。若以5分钟作为每台设备的采集周期，每台设备1个 数据流，则可支撑15万台设备，已达到业务要求。该程序能在数据量大时，持续不间断正确处 理数据至少1小时左右。能稳定支持数据采集处理。部门管理体系文件-能耗监控项目性能测试报告V1.0发现的问题问题编号问题描述当前状态3-1Handle程序处理数据入库速度太慢（速度30条/秒）。已修复3-2Handle程序处理数据入库有数据遗漏。已修复3-3Handle程序线程池占满后报错，程序崩溃无法继续运行。已修

33、复以上各问题处理详情如下：【问题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.concur

34、rent.RejectedExecutionException: null问题原因：程序问题。解决方案：修改程序处理。部门管理体系文件-能耗监控项目性能测试报告V1.02.5.4 定时任务测试结果定时任务主要测试任务执行时间，详细测试结果见下表：定时任务名称执行频率数据量执行耗时程序是否报错测试结果检查设备状态每30分钟一次476041秒否通过清除数据库表数据每天3:05执行6个表的数据1秒内否通过Data表统计入Statistics 表每天2:05执行91万数据86秒否通过整点报告每1小时执行一次10002142秒否通过MN策略下发每天00:05执行3510121秒否通过定时策略扫描每10分

35、钟一次351011秒内否通过定时策略下发不定时1509秒否通过系统资源占用没任务执行时：应用cpu占用0.7%,内存占用4.1% ；数据库cpu0.7%，21.5%有多个任务同时执行时：应用cpu占用50%,内存占用10% ；数据库cpu25%，58%测试结论按照4万设备的业务量来算，所有定时任务的执行速度都能够满足业务需求。发现的问题问题编号问题描述当前状态4-1整点报告任务执行时报错（邮箱无法使用）。已修复4-2整点报告任务执行时报错（时间格式问题）。已修复4-3测试定时策略扫描任务时，有一个容错问题，程序读脏数据报错。已修复4-4检查设备状态定时任务运行时报错。已修复4-5检查设备状态时

36、，正常设备和数据流的状态被标为异常。已修复部门管理体系文件-能耗监控项目性能测试报告V1.0以上各问题处理详情如下：【问题4-1】整点报告任务执行时报错：javax.mail.MessagingException: Unknown SMTP host: ;问题原因：因为整点报告下发邮件使用的是开发人员的私人163邮箱，频繁发邮件的话会被当 成垃圾邮箱禁用，禁用后程序会报错。解决方案：加内存重新申请个企业邮箱进行替换（截止发报告时，仍未申请到邮箱进行替换）【问题4-2】整点报告任务执行时报错：java.lang.NumberFormatException: For input string: 2

37、0015E.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】检查设

38、备状态时，正常设备和数据流的状态被标为异常。问题原因：程序问题解决方案：修改程序解决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秒内