传感器观测服务的性能评估与方法

引文格式： 陈能成，张伟杰，王晓蕾.传感器观测服务的性能评估与方法[J].测绘通报，2015(4)：61-64.DOI:10.13474/j.cnki.11-2246.2015.0111

传感器观测服务的性能评估与方法

陈能成，张伟杰，王晓蕾

(武汉大学测绘遥感信息工程国家重点实验室，湖北 武汉 430079)

PerformanceEvaluationandMethodforSensorObservationService

CHENNengcheng,ZHANGWeijie,WANGXiaolei

摘要：传感器观测服务是传感网的核心服务，用于管理和获取异构传感器的元数据和观测数据。在一定的硬件和软件条件下，评估传感器观测服务的性能有助于发挥传感网监测目标地物时的最优性能。本文以服务性能的响应时间为评估标准，提出了传感器观测服务性能的评估方法。此方法分别从不同的操作和软件配置等方面进行了响应时间的评估，分析出传感器观测服务中不同操作的性能特征，提高了传感器观测服务的设计与部署效率。

关键词：传感器观测服务；传感网；性能；评估

中图分类号：P24

收稿日期：2014-03-07

基金项目：国家863计划(2013AA01A608)；国家自然科学基金(41171315)

作者简介：陈能成(1974—)，男，教授，博士生导师，研究方向为网络地理信息系统与服务、传感网、模型网和智慧城市。E-mail：cnc@whu.edu.cn

一、引言

传感器观测服务(sensorobservationservice，SOS)可以提供获取异构传感器的元数据和观测数据的标准化接口，是传感网(sensorweb)的核心服务之一[1-2]，其优劣对于传感网服务体系的性能具有重要的影响。

国外学者对SOS中核心操作GetObservation的响应时间[3]、移动网络下响应内容大小[4]以及多种SOS的实现软件[5]等进行了对比分析。这些分析评价工作对SOS的性能评估和改进有一定的借鉴意义，但缺少针对SOS在不同的操作、软件配置和并发请求数情况下性能表现的评估。如何针对SOS的性能进行更综合的评估，尤其是在一定的硬件和软件条件下的性能评估，是现今亟待解决的问题。这不仅对SOS软件实现的设计与优化提供了有用参考，同时对合理选用SOS具有重要的指导意义。

针对上述情况，本文提出了针对SOS各服务操作和不同软件配置等方面进行评估的方法，分析出SOS在多种环境下的性能特征，极大地便利了传感器观测服务软件的设计与优化部署。

二、传感器观测服务

SOS可以提供的操作包括核心操作、事务操作和高级操作3大类[6]。其中核心操作和事务操作是SOS日常运行的主要操作，能满足从获取SOS服务能力、传感器注册、插入观测数据到获取传感器信息和观测数据等的整个流程。

1) 核心操作。①GetCapabilities(GC)：获取服务能力信息；②DescribeSensor(DS)：获取传感器信息；③GetObservation(GO)：获取传感器观测数据。

2) 事务操作。①RegisterSensor(RS)：注册传感器；②InsertObservation(IO)：插入观测数据。

各操作运行顺序如图 1所示。

图1　SOS核心操作与事务操作运行顺序

三、评估方法

1. 测试原则

(1) 响应时间测试

SOS是基于传感器观测数据的共享操作标准。对于客户端来说，SOS软件的服务响应时间至关重要，测试时应包含此项指标。

(2) 测试所有核心操作

标准的SOS必须提供GC、GO和DS这3个核心操作，这3个操作的性能是评估SOS共享传感器信息及观测数据实际效果的关键部分。

(3) 兼顾包含空间特性的操作

传感器的空间位置对于用户解译和使用观测数据至关重要，SOS的一个重要特性是支持空间数据和空间相关的过滤操作。测试时应基于不同空间位置的数据，并对同一操作的包含与不包含空间过滤分别进行测试，以便能够更准确地反映SOS的性能状况。

2. 测试设计

为了综合评估SOS的服务性能，本文设置以下3类测试场景。

(1) 软件配置测试的准备测试

在一定硬件条件下，不同的软件配置如Web服务容器、数据库的配置不同，会导致不同的性能表现，因此在SOS各操作的测试之前，需先对不同软件环境配置下的SOS进行测试，从中选出较优的软件配置。分别对以下4种情况进行GetObservation测试：①默认SOS软件配置；②仅调整Web服务容器参数；③仅调整数据库配置参数；④同时调整前面两个参数。

(2)SOS的每个核心操作和事务操作测试

每个操作请求按如下设置：①GC，请求所有内容：操作元数据信息(OperationsMetadata)、服务标识(ServiceIdentification)、服务提供者(ServiceProvider)、过滤能力(Filter_Capabilities)、内容(Contents)；②DS，指定传感器；③GO，指定观测数据的时间段、观测属性、传感器和空间范围；④RS，包含SensorML[7]的系统(System)及其基本的唯一标识(Identification)和观测输出(Outputs)；⑤IO，包含OM(ObservationsandMeasurements)[8]的必须元素，观测数据中包含空间值、文本值和数量值。

(3)GetObservation空间与非空间操作测试

分别对包含、不包含空间位置过滤的GO进行测试。为避免返回的观测数据大小不一致造成的影响，测试时设置空间过滤方式为“与武汉市的最小包围盒相交”，且不包含空间过滤时，返回一样的数据。

针对以上3类场景，设置每个测试并发用户数分别为1、10、50、100、200、500和1000，每次请求响应完毕后立即进行下一次请求，分别连续测试5min，并在两台相同配置的电脑上重复5次，以尽量减少异常个例对结果的影响。

3. 测试数据

为保证测试的准确性，SOS的测试数据应符合以下条件：①包含多个传感器的注册信息和观测数据信息；②数据量应适量，不能过大，否则SOS的数据库性能会严重影响整体响应时间；③观测数据应同时包含空间观测值和非空间观测值，并且空间观测值应具有一定的随机性。

本测试数据从武汉市1万多辆浮动车中随机选取100辆的连续观测数据，预先注册并插入到SOS数据库。其中，每次观测数据包含4个观测值：车的GPS位置(空间点值)、车速(数量值)、车向(数量值)和车的状态(文本值)。原始数据的观测频率约为40s/次，在不影响测试的前提下，为便于直观统计，将数据按1h/次重新分配时间值。选取基于此频率的30d的观测数据作为被测试数据，即共100×4×24×30=288000个观测值，其中空间观测值为72000个，随机地分布在武汉市行政区划内。

4. 测试环境与工具

(1) 硬件环境

选取4台相同的工作站，2台用于部署相互独立的SOS，防止单台工作站存在特殊情况；2台用于独立运行测试软件模拟的SOS客户端。其运行在同一交换机局域网中。每台工作站的配置见表1。

表1　硬件配置

(2) 软件环境

测试对象是52northSOS[9]，它支持的SOS操作最齐全，发展较为完善，基于Java和PostgreSQL(Pg)、开源、版本为3.5.x，数据库结构中包含B树和Gist索引。测试软件采用被广泛用于Web性能测试的开源测试工具ApacheJMeter，版本为2.11。详细软件环境见表2。

表2　软件环境

四、测试结果与分析

1. 不同软件配置的测试分析

不同软件配置参数组合难以穷尽，本文仅选取比默认配置更优的配置作为参考[10]。以减少磁盘I/O和减轻CPU负荷为主要目的选取参数：①提高Tomcat的JVM内存参-Xmx=4048MBXms=3000MB，服务器模式-server，最大等待数(acceptCount)=2000，最大线程数(maxThreads)=500；②提高PostgreSQL缓存effective_cache_size=1024MB、shared_buffers= 1024MB、work_mem=8MB、降低检查点频率checkpoint_segments=32。

测试中，所有GO均包含空间过滤参数。GO的响应大小为47.9KB，响应时间如表3及如图2所示。

表3　 GetObservation各配置下平均响应时间　 ms

图2　GetObservation各配置下平均响应时间

从图2可看出，同时调整Tomcat和PostgreSQL参数的结果最优，相比于默认配置，单用户时平均响应时间降低13%，1000并发时降低15%。这说明通过调整Web服务器与数据库的参数有助于在一定程度上提升SOS的服务性能，以此参数配置为基础能够比默认配置更客观地评价出SOS各操作的性能。

2. 不同操作类型的测试分析

本场景基于场景1中同时调整Web服务器和数据库参数，对SOS的5个主要操作进行测试。其中，GO包含与武汉市最小包围盒相交的空间过滤，每次获取1个传感器的720次观测结果，共2880个观测值；IO每次发送一次观测的4个观测值。特别的，RS和IO的测试也是原有测试数据基础，在测试过程中会逐渐增加传感器和观测数据。测试结果如表4和图3所示。

表4　各操作的平均响应时间　 ms

图3　各操作的平均响应时间

不同并发情况下，各操作响应时间均大致呈现线性增长。DS最快，单用户的响应时间为1ms，即使在1000并发时也仅550ms。GC的响应时间最慢，即使在单用户的情况下也接近0.5s，响应数据大小约60KB，这与GC查询的内容较多有较大关系。GO在单用户时保持在115ms左右，但在200并发时接近10s的响应时间，在实时性十分严格且并发数较大的应用中应慎重考虑。事务操作中，RS和IO表现出相对较好的性能，单用户时均不超过15ms，1000并发时不超过10s。

3.GetObservation有无空间过滤的测试分析

包含与不包含空间过滤参数的GO的响应内容完全一致，大小均为47.9KB，测试结果的响应时间同样随并发数增长而呈类线性增大，见表3中的列“Tomcat&Pg”和“无空间过滤”，其趋势如图4所示。

包含空间过滤参数的响应时间是不包含时的3倍以上，因此对于SOS客户端用户而言，若能获取同样的所需观测数据，则应尽量避免在GO中加入空间过滤参数，以减少响应的等待时间。

图4　有无空间过滤的GetObservation平均响应时间

4. 综合分析

一般的，每个SOS客户端获取服务元数据信息只需一次GC[6]，GC的响应时间较长，但只影响一次。RS和DS只需对每个传感器注册和获取一次。观测数据由传感器自身或传感器所在网关向SOS发送IO请求，也可直接存入数据库以避免IO。根据不同需求可能会请求多次数据，若在近实时应用中，GO可能与传感器观测保持一致频率，是SOS所有操作中使用最频繁的操作。再结合前面测试分析可知，GO操作的响应时间仅次于GetCapabilities，是RS的近10倍，IO的20多倍。因此，在SOS的代码设计和实际部署时，优化GO特别是包含空间参数的GO的响应性能，是提升SOS整体性能的关键。

五、结束语

本文针对传感器观测服务包含多个操作和支持空间过滤的特点，提出了以响应时间为评价因子针对多个操作及空间过滤参数的综合测试方法。依据这种评估方法，设计了相应的测试场景，从而实现了在特定硬件条件下对SOS常用核心操作和事务操作的多种并发条件测试评估。评估结果表明，优化包含空间参数的获取观测数据操作， 可以显著提升服务的整体性能， 可以为传感器观测服务的软件编码和实际应用时的按需部署提供重要的参考依据。

参考文献：

[1]BRÖRINGA,ECHTERHOFFJ,JIRKAS,etal.NewGenerationSensorWebEnablement[J].Sensors, 2011, 11(3)：2652-2699.

[2]CHENN,DIL,YUG,etal.AFlexibleGeospatialSensorObservationServiceforDiverseSensorDataBasedonWebService[J].ISPRSJournalofPhotogrammetryandRemoteSensing, 2009, 64(2)：234-242.

[3]POORAZIZIME,LIANGSHL,HUNTERAJS.TestingofSensorObservationServices:aPerformanceEvaluation[C]∥TheFirstACMSIGSPATIALInternationalWorkshoponSensorWebEnablement.[S.l.]：ACM, 2012：32-38.

[4]TAMAYOA,CARLOSG,JOAQUNH.UsingSWEStandardsforUbiquitousEnvironmentalSensing:aPerformanceAnalysis[J].Sensors, 2011, 12(9)：12026-12051.

[5]MCFERRENG,HOHLSD,FLEMINGG,etal.EvaluatingSensorObservationServiceImplementations[C]∥GeoscienceandRemoteSensingSymposium.[S.l.]：IEEE, 2009.

[6]NAA,PRIESTM.SensorObservationService[S].[S.l.]:OpenGISImplementationSpecificationOGC, 2007.

[7]BOTTSM.SensorModelLanguage(SensorML)ImplementationSpecification[S].[S.l.]:OpenGISImplementationSpecificationOGC, 2007.

[8]COXS.ObservationsandMeasurements-Part1-ObservationSchema[S].[S.l.]：OpenGISImplementationSpecificationOGC, 2007.

[9]52north.SensorObservationService[EB/OL].[2013-12-19].http:∥52north.org/communities/sensorweb/sos/.

[10]高张, 康小军. 提高Tomcat服务器运行性能的研究[J]. 计算机与数字工程, 2008, 36(10)：203-205.