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

《物联网能耗监控项目性能测试报告V0全解.docx》由会员分享，可在线阅读，更多相关《物联网能耗监控项目性能测试报告V0全解.docx（26页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、文档编号NH_XN_01文档类别测试文档文档级别高中移动物联网能耗监控平台V2.0性能测试报告的各块功能在单次操作下，响应时间不超过3秒。排除明显的性能问题。2、选取多个典型业务场景，对整个平台进行负载测试。依次加大并发数，直到请求响应报 错（包括服务器拒绝、超时、程序报错）或者系统、程序崩溃。由于时间问题，此次不单 独针对单个业务场景做测试，如果在测试过程中发现某个业务场景性能可能存在问题，再 单独压测。3、平台稳定性测试，在用户访问峰值压力下，持续访问平台功能，测试平台是否能长时间 稳定运行。预期得到的测试结果指标有:指标名称指标说明限制条件最优并发数在一定限制条件下，平台所能承受的最大并

2、发数（严格并发）在这个并发数下，平均响应时间不超过5秒，系统无报错，服务器系统资源cpu不超过75%,内存不超过75%最大吞吐量系统每秒能够处理的最大请求数。单位：请求数/秒在这个吞吐量下，平均响应时间不超过5秒，系统无报错，服务器平均系统资源cpu不超过75%,内存不超过75%平均响应时间最优并发数下的系统平均响应时间条件同最优并发数持续稳定运行时间在最优并发数下持续运行的时间持续稳定运行期间系统不报错，不崩 溃，系统资源占用稳定。一般不小于 1小时。针对TERMINAL数据收发服务的测试采用如下策略：1、先测试单次收发数据的处理响应时间，排除明显性能问题。部门管理体系文件-能耗监控项目性能

3、测试报告V1.02、再分别测试数据接收和下发的处理速度。测试数据接收速度的时候，写程序用EDP协 议模拟设备云直接上传大量的实时监控数据。发送完后统计全部写入消息队列的时间、 验证正确率。测试下发时，先在消息队列中加入大量下发数据，再开启程序发送到设备云，记录消息全部出队列时间，即下发完成耗时。3、最后测试程序较长时间运行的稳定性。4、测试过程中需要监控消息队列的处理情况和系统资源占用情况。预期得到的测试结果指标有：指标名称指标说明限制条件数据接收处理速度在一定限制条件下，程序处理消息的速度（单位：消息数/秒）在这个处理速度下，消息处理错误率为0,系统无报错，服务器系统资源在处理完成后回落到正

4、常值。数据下发处理速度在一定限制条件下，程序下发消息的速度（单位：消息数/秒）在这个处理速度下，消息处理错误率为0,系统无报错，服务器系统资源在处理完成后回落到正常值。持续稳定运行时间在整体最大处理速度下，程序能持续稳定运行的时间运行期间系统不报错，不崩溃，系统 资源占用稳定（CPU持续值不超过 85%,内存持续值不超过85%,且执 行完后迅速回落到正常值）。一般不小于1小时。针对HANDLE数据处理服务程序的测试采用如下策略：模拟真实场景准备大量各种业务数据消息进入消息队列，开启消息处理程序执行解 析入库操作，执行完后记录处理时间，校验处理结果的正确性。预期得到的测试结果指标有：消息处理速度

5、XX条/秒和最小持续稳定运行时间。针对定时任务的测试策略和方法如下：在测试数据库中加入一定量的真实业务数据，然后开启各个定时任务执行，记录定时 任务的执行时间和资源消耗情况，校验处理结果的正确性。预期得到的测试结果指标有：每个定时任务的执行耗时。部门管理体系文件能耗监控项目性能测试报告V1.02. 3测试工具及程序本次性能测试要使用到的测试工具和用途如下:工具名称工具用途工具版本是否需培训Jmeter用于测试能耗监控平台性能V2. 13否FireBug用于排查网页性能V2. 0. 8否本次能耗监控平台测试使用开源性能测试工具Jmeter V2. 13模拟用户发送请求访问 平台，通过Jmeter

6、线程组控制生成虚拟用户数，对被测系统进行负载测试。如果在 测试 web应用过程中发现某些页面单次访问加载时间很慢则采用FireBug工具进行排 查。对于 Linux系统的服务器使用）r6自带的监控插件来监控。本次性能测试要使用到的测试程序及其功能定义如下:程序名称程序主要实现功能程序开发语言使用说明feinnoonenet_emulator模拟DTU设备向设备云上传监控数据JAVA启动后每隔5分钟发送4.6万条消息到terminal程序2. 4系统资源监控及关注指标每次压力测试结果数据由测试工具Jmeter自带的监听器搜集成聚合报告。Jmeter聚合报告需关注的参数和指标如下：指标名称性能参数

7、说明正常范围值平均响应时间average指单次测试总请求数的平均响应时间。小于3-5秒中间时间median中位数，也就是50 %用户的响应时间小于3秒90%用户响应时间90%_line90 %用户的响应时间小于5秒最大响应时间max单次测试中最大的响应时间小于5秒事务错误率error%本次测试中错误的请求数/请求总数等于0%吞吐量Throughput表示每秒完成的请求数越大越好每秒数据量KB/Sec每秒从服务器端接收到的数据量略小于带宽Linux服务器资源占用监控工具选用Jmeter自带的监控插件来监控，具体需要监控的服务器指标有:指标名称说明正常范围值CPU使用率(%CPU )程序的cpu的

8、使用率不超过80%内存内存使用率（MEM ）程序的内存使用率不超过75%平均负载(Lord Average )过去1分钟、5分钟、15分钟内运行进程队列中 的平均进程数量。不超过5对于数据库需要监控的指标有数据库连接数、SQL执行时间、监控执行太慢的SQL。对于Tomcat web服务器需要监控的有：当前连接请求数、1窈日志。2. 5测试结果2. 5. 1能耗监控平台2. 5. 1. 1测试结果根据测试方案既定的测试策略和方法，测试出能耗监控平台（web应用）性能情 况如 下。主要业务功能的单次响应时间能耗监控平台主要页面单次访问耗时测试前置条件业务数据已准备完毕：1万用户数据、1万企业、4万

9、设备。使用工具FireBUG： c页面加载耗时分析问题编号问题描述当前状态1-1持续运行加数据脚本后java堆内存溢出。已修复1-2加压并发100时报错tomcat线程被占满。已修复1-3查询类功能加压并发到200,数据库cpu 一直保持100%。已修复1-4并发500访问时报错，数据库连接池连接数不够用。已修复1-5并发500访问时，部分程序功能报404错误。已修复以上各问题处理详情如下:【问题1T】持续运行加数据脚本后报错java.lang.OutOfMemoryError: PermGen space问题原因：JAVA堆PermGen space内存溢出。解决方案：加内存，手动设置Max

10、PermSize大小修改TOMCAT_HOME/bin/catalina.sh在 /echoUsing CATALINA_BASE: $CATALINA_BASE 0上面加入：JAVA_OPTS=-server-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【问

11、题查询类功能加压并发到200,数据库cpu一直保持100%,数据库资源占用大，平 均响应时间长，tomcat线程大多数处于等待中。问题原因：数据库没有加索引、部分SQL执行耗时较长(有问题的SQL见附录)。解决方案：添加数据库索引，优化SQL,已完成优化。【问题并发500的时候，响应时间太长，程序报错：nested exception isorg.hibernate.exception.GenericJDBCException: Could not open connectioncom.alibaba.druid.pool.GetConnectionTimeoutException: loop

12、WaitCount lz wait millis60000问题原因：数据库连接数太少，只有32个。连接池溢出导致的等待时间过长所以响应太慢。解决方案：修改数据库连接池配置，增大连接数至500。【问题1-5并发500的时候，部分功能出现404错误。问题原因：不详解决方案：优化了 SQL增大了数据库连接池后，该问题没有再复现。2. 5. 2数据收发模块(Terminal)测试与设备云交互的数据收发模块分为两部分：一部分是数据接收、另一部分是数据 下发。主要测试程序收发数据的速度。2. 5. 2. 1测试结果测试数据上传下发消息数据上传下发测试测试目的测试程序处理数据接收下发的速度。上传/下发处理消

13、息总量总耗时错误率系统资源占用测试结果上传消息294595秒0应用：cpu45%,内存6.2%通过463638秒0应用：cpu50%,内存8%通过75416268小时0应用：cpu50.0%,内存 10.2%通过下发消息3510180秒0应用：cpu5%,内存6%通过31万9分钟0应用：cpu6.4%,内存 9.4%通过持续两天，每分 钟3万数据80秒/次0应用：cpu8%,内存10%通过测试结论Terminal程序接收上传数据速度为：5892条/秒Terminal程序处理下发数据速度为：439条/秒备注说明1）假设有10万台设备，每台设备5条数据流，则完成一次采集数据50万上传的时间是85

14、秒，可以满足业务需求。2）每天凌晨设备指令下发是10万，全部下发完毕是3.7分钟，也满足业务需求。2.5. 2. 2发现的问题暂无2. 5.3消息解析程序（Handle）2. 5. 3. 1测试结果部门管理体系文件-能耗监控项目性能测试报告V1.0消息解析程序测试测试目的测试消息解析程序的处理速度消息总数总耗时平均入库速度是否全部入库系统资源占用测试结果463631.5分钟30908条/分钟是应用：cpu45%,内存30%数据 库：cpu35%，内存88%队列/缓 存：cpu10%,内存 10%通过32454110分钟32454条份钟是应用：cpu57%,内存30.7%数据 库：cpu35%

15、,内存88%队歹旷缓 存:cpu10.8%,内存 10%通过171543148分钟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万台设备，已达到业务要求。该程序能在数据量大时，持续不间断

16、正确处理数据至 少1小时左右。能稳定支持数据采集处理。3.5. 3. 2发现的问题问题编号问题描述当前状态3-1Handle程序处理数据入库速度太慢（速度30条/秒）。已修复3-2Handle程序处理数据入库有数据遗漏。已修复3-3Handle程序线程池占满后报错，程序崩溃无法继续运行。已修复以上各问题处理详情如下:【问题3-1 Handle程序处理数据入库速度太慢（速度30条/秒）。问题原因：程序采用单线程处理，且每条数据入库都要去打开连接写数据库。解决方案：程序采用多线程处理。【问题32】Handle程序处理数据入库有数据遗漏（ 68246条数据少入库50条）。问题原因：程序采用多线程处理

17、后数据有遗漏。解决方案：修改程序处理。【问题33】Handle程序线程池占满后报错，程序崩溃无法继续运行。com.feinno.energy.utils.thread.SimpleThreadPool - The work queue is full!java.util.concurrent.RejectedExecutionException: null问题原因：程序问题。解决方案：修改程序处理。文修订记录版本日期版本描述作者检查人/日期备注2015. 06. 291.0创建文档唐晓文部门管理体系文件-能耗监控项目性能测试报告V1.02. 5.4定时任务2. 5. 4. 1测试结果定时任务主

18、要测试任务执行时间，详细测试结果见下表:定时任务名称执行频率数据量执行耗时程序是否报错测试结果检查设备状态每30分钟一次476041秒否通过清除数据库表数据每天3:05执行6个表的数据1秒内否通过Data表统计入Statistics 表每天2:05执行91万数据86秒否通过整点报告每1小时执行一次10002142秒否通过MN策略下发每天00:05执行3510121秒否通过定时策略扫描每10分钟一次351011秒内否通过定时策略下发不定时1509秒否通过系统资源占用没任务执行时：应用cpu占用0.7%,内存占用4.1% ;数据库cpu0.7% , 21.5%有多个任务同时执行时：应用cpu占用5

19、0%,内存占用10% ;数据库cpu25% , 58%测试结论按照4万设备的业务量来算，所有定时任务的执行速度都能够满足业务需求。2. 5. 4. 2发现的问题部门管理体系文件-能耗监控项目性能测试报告V1.0 以上各问题处理详情如下：问题编号问题描述当前状态4-1整点报告任务执行时报错（邮箱无法使用）。已修复4-2整点报告任务执行时报错（时间格式问题）。已修复4-3测试定时策略扫描任务时，有一个容错问题，程序读脏数据报错。已修复4-4检查设备状态定时任务运行时报错。已修复4-5检查设备状态时，正常设备和数据流的状态被标为异常。已修复【问题 41】整点报告任务执行时报错：javax.mail.

20、MessagingException: Unknown SMTP host: ;问题原因：因为整点报告下发邮件使用的是开发人员的私人163邮箱，频繁发邮件的话会被当成垃圾 邮箱禁用，禁用后程序会报错。解决方案：加内存重新申请个企业邮箱进行替换（截止发报告时，仍未申请到邮箱进行替换）【问题42】整点报告任务执行时报错：java.lang.NumberFormatException: For input string: 20015E.20015E44问题原因：程序代码问题解决方案：修改程序解决【问题43】测试定时策略扫描任务时，报错：java.text.ParseException: Unpars

21、eable date: 2015-06-16 null）问题原因：容错问题，程序读脏数据报错解决方案：修改程序解决【问题44】检查设备状态定时任务运行时报错。com.feinno.energy.quartz.task.CheckDeviceTaskScheduler -检查设备任务失败java.lang.NullPointerException: null问题原因：程序问题 解决方案：修改程序解决【问题45】检查设备状态时，正常设备和数据流的状态被标为异常。问题原因：程序问题解决方案：修改程序解决3测试结论指标监控项目性能测试结果能耗监控平台性能情况1、能耗监控平台单机最大可支持600人同时在

22、线访问，平均响应时间小于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万消

23、息量总耗时1.5分钟，平均3万条/秒入库。2、检查设备定时任务执行耗时1秒。3、凌晨清楚数据库表数据任务执行1秒内完成。4、当日能耗统计任务执行138万数据耗时103秒。5、整点报告定时任务执行耗时142秒。6、MN策略下发（35101条数据）定时任务执行耗时21秒。7、定时策略定点扫描任务耗时1秒内。8、定时策略下发（164条数据）定时任务执行耗时9秒。部门管理体系文件能耗监控项目性能测试报告V1.0测试结果数据整体分析根据能耗监控系统的架构结合以上性能数据，对系统有10万台设备接入后的性能进行如下分析：1、10万台设备采集数据同时上传经过terminal程序进入队列的时间大约20秒，进入队

24、列后handle程序全部处 理入库的耗时大约是3分钟，设备采集周期为5分钟，故不会产生数据积压延迟，满足业务要求。若以5分钟作 为每台设备的采集周期，每台设备1个数据流，则最大可支撑15万台设备同时采集数据。2、假设10万台设备大约来自于1000个用户（每个100台），目前系统单机满足访问峰值为600,根据平均用 户并发数计算公式C=nL/T来计算（n是每天登录用户数，L是每个用户每天使用系统的时长预测为1小时，丁是 系统每天有用户使用的时间段预测为8小时），则系统每天可以支持4800个用户访问，能够满足业务需求。且 以上结果只是单机性能，如进行横向扩展，则每增加一台机器预测可以支持的用户量增

25、加80%03、系统的后台定时任务大多设置在凌晨执行，且在业务量级为4万台设备时，执行速度仍保持在秒的级另力且 资源占用率较低。故此模块不存在性能瓶颈，不会对整体性能造成影响。结论概述通过上述分析可得出以下结论：1、能耗监控系统V2.0能够满足10万台终端设备接入，最大能够满足15万台终端设备接入（注意：此处 假设 每台设备1个数据流，如设备数据流增加则设备数对应成倍减少，例如每台设备5个数据流，则最大设备支持数 为3万）。2、能耗监控平台单机最大可支持600人并发访问操作，每天可支持4800人登录访问（推算值）。系统整体性能效果请参见下方演示 0：有下设1Q7J条能耗监控系统V2. 0性能情况

26、演小图h上传下发程。 序 jTexoiijial6000条/电500条/秒止传渔据队300 条/QucvV spring, queue, tuxU小发般犯队列rmcUuene数据解析Handl/程序定时下.发程序500条/秒八库写缓存图三：能耗监控平台V2系统整体性能情况演示图测试结论：能耗监控平台V2.0满足预期设计的性能需求，测试通过。4测试总结此次性能测试共发现12个问题，问题统计如下： 中间件/程序配置问题：3个数据库/SQL问题：1个（包括多个SQL优化和索引优化） 程序代码问题：6个其他：2个根据以上问题有如下优化建议供项目组参考，以避免后续发生类似问题：1、希望以后在规划系统性能

27、时就考虑好相关服务器的优化配置参数。2、数据库SQL编写要加强，避免编写出执行效率低下的SQL。数据库设计时就要把索 引规划好。加强数据库批量入库技术性能研究、总结推广。3、程序容错性有待加强。5附录附录1：此次性能测试的测试用例执行结果附录2：此次性能测试发现的问题报错文件 附录3：此次性能测试的测试脚本和测试程序目录1 测试概述41.1 项目背景41.2 测试目的41.3 术语、定义和缩略语 41.4 测试内容和范围5测试执行过程和结果51. 1测试对象和测试环境52. 1. 1测试对象53. 1.2网络拓扑结构84. 1.3硬件及软件环境92. 2测试策略和方法 103. 3测试工具及程

28、序 124. 4系统资源监控及关注指标125. 5测试结果132.5. 1 能耗监控平台 132. 5. 2与设备云交互的数据收发模块 17消息解析程序 18定时任务20测试结论指标223 测试总结25附录251测试概述1.1项目背景能耗监控平台将主要从能耗分析、预估及对应节能策略入手，主要完成对能源终端的 监控、管理、分析、预估，并根据以上数据进行对应节能策略配置的管理系统。平台主要 功能详见能耗监控平台V2.0需求规格说明书。L2测试目的此次性能测试的目的是：通过在测试环境中，运用性能测试策略和测试工具对能 耗 监控平台的关键节点进行性能测试，最终得出各系统节点的性能情况指标数据，以 此来

29、 对整个能耗监控系统性能做出评估。L3术语、定义和缩略语名称能耗监控系统中移动物联网设备云平台解释能耗监测系统是指通过对能耗设备和能耗建筑安装分类和 分项能耗计量装置，采用物联网等技术手段及时采集能耗 数据，实现重点建筑、设备能耗的在线监测和动态分析功 能的硬件系统和软件系统的统称。中移设备云平台是指中移物联网有限公司自主研发的开 放、共赢OneNET平台，为各种跨平台物联网应用、行业解 决方案，提供简便的云端接入、存储、计算和展现。响应时间请求从发送开始到接收完服务器响应结果的时间吞吐量吞吐量系统最大的每秒处理请求量，单位是：请求/秒部门管理体系文件-能耗监控项目性能测试报告V1.01.4测

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

31、数据库缓存图一：能耗监控系统业务数据流向图如上图所示，标红的为此次性能测试的主要测试对象，共有如下四个:1）能耗监控平台web应用的整体性能（包括缓存和数据库）2）与设备云交互的数据收发模块（TERMINAL）3）消息解析服务程序（HANDLE）4）定时任务（主要是统计分析、下发等定时任务功能）各测试对象的详细说明如下：能耗监控平台（前台web应用）能耗监控平台前台应用的主要功能包括实时控制、设备控制、设备管理、统计分析、 审计公示、系统管理六大体系组成。由于审计公示和系统管理使用频率非常低，所以不 作为此次测试对象。其余的功能模块按优先级由高到低依次递减为：实时监控、统计分 析、设备控制、设

32、备管理。在此选取了部分主要业务场景作为测试对象，一共 有如下几 占 /、场景名称业务场景描述使用占比数量级登录用户登录系统打开首页不计1万用户量实时监控用户登录系统，到实时监控页面查看设备实时监控数据。（包含能耗监控、实时抄表、设备状态监控功能）40%4万台设备的实时监控数据统计分析用户登录系统，查看各项统计分析数据。30%4万台设备设备管理用户登录系统增删改查设备信息、增删改查建筑物信息。20%4万台设备4万建筑物信息设备控制用户登录系统，查看MN策略、定时策略，查看控制日志。10%4万台设备对于web应用主要测试的是平台最大支持在线使用人数，平均响应时间和吞吐量。与设备云交互的数据收发模块

33、（TERMINAL）处理能耗监控与设备云收发数据的程序是TERMINAL,双方根据设备云接入接口进 行交互。设备云获取数据消息为ModBus协议。服务功能功能描述分析使用占比数量级接收设备云透传过来的数据这块功能包括以下几个步骤：1）设备云下发消息给DTU设备获取监控数据。2） DTU设备向设备云传输监控数据。3）设备云存储转发DTU上传给它的数据。90%4万台设备的监控数据4） TERMINAL接收设备云透传过来的数据并写入消息队列。从1-4步骤都要测试。下发设备命令数据到终端这块功能包括以下几个步骤：1）平台下发指令到消息队列。2） TERMINAL程序到消息队列去获取下发指令下发到设备云

34、。3）设备云转发到DTU设备。只测试1-2步骤。10%4万台设备登录设备云与设备云保持心跳连接TERMINAL收发数据之前需要登录到设备云，登录后需要定时发送心跳保持激活状态。忽略不计每4分钟发一 次，每天360 次。针对这块程序主要测试的是程序收发数据的速度。 消息解析程序（HANDLE）该程序是用于从消息队列中获取信息并解析成数据写入缓存和数据库中。是主动从消息队列里取数据进行处理。针对这块程序主要测试程序的处理速度和稳定 性。定时任务定时任务一共有如下7个：1）检查设备状态2）清楚数据库表数据3） Data 表统计如 Statistics 表4）整点报告5） MN策略下发6）定时策略扫描

35、7）定时策略下发这块主要测试的是定时任务在大数据量的情况下的执行速度。2. 1. 2网络拓扑结构能耗监控平台的网络拓扑结构图如下:DTU设备中移物联网设备云平台智能设备缓存服务器X2服务器X2Patrol运营维护人员管理后台物联网管理人员消息队列 服务器X2数据解析处理 服务器X2图二：能耗监控平台V2系统网络拓扑结构图各个测试对象对应上图中的部署机器如下:1） “Patrol”部署的是能耗监控平台web应用（前台）、平台缓存是在“缓存服务 器”、平台数据库是在“数据库”服务器上。2）与设备云交互的数据收发模块（TERMINAL程序）部署在“接口服务器”上。3）消息解析程序（HANDLE）部署

36、在“数据解析处理服务器”上。消息队列单独部署在 “消息队列服务器”上。由于测试环境机器紧张，所以除了数据库和接口服务器是单独部署在一台机器上，其 他应用程序全部部署在一台机器上。测试时会对性能测试结果造成一定影响。2.1. 3硬件及软件环境测试环境机器配置:机型CPU内存硬盘数量和用途PC兼容机1134G500G部署应用程序，一共包括：web应用、缓存、消息队列、消息解析程序。CentOS系统PC兼容机2132G500G部署MySQL数据库:CentOS系统+mysqlPC兼容机3134G500G部署接口程序TERMINAL:CentOS 系统+Tomcat加压测试机环境:机型CPU内存硬盘数量和用途PC兼容机134G500G2台，用于运行测试工具，对系统加压。软件环境:win7系统+JDKL 7+Jmeter部门管理体系文件能耗监控项目性能测试报告V1.02. 2测试策略和方法针对能耗监控平台（web应用）采用的测试策略如下：1、首先在数据库中把业务数据量加到标准值后，单次访问各主要页面功能，先确保平台上