Database Reference
In-Depth Information
evaluation of the proposed architecture have been provided by Worldsensing [ 19 ]
from one of the company's deployments in a real-life scenario, used to control
parking spots on streets. The traces are a subset of an entire deployment (more
than 10,000 sensors) with information from 400 sensors over a 3-month period.
Experimental Setup. Each of 604k parking spots' data has been used in our
cloud infrastructure using a Java-based data generator, which periodically selects
an available protocol (HTTP, CoAP or MQTT) on a random basis and sends
raw data to the corresponding acquisition node interface. Once the raw data
has been received by the acquisition layer, they are forwarded to the dedicated
normalization Exchange, where corresponding nodes enrich incoming data with
parking zone's details, retrieved from an external database. Once the normaliza-
tion module has completed its process, it sends the structured data to the Graph
Framework, allowing the processing of the enriched data. This Graph Framework
is composed by 7 Core Nodes and 7 Application Nodes. The processed data fol-
lows a path based on routing keys, until reaching the architecture's final external
listener. Each Application node is interested in detecting changes of parking spot
data, related to specific parking zones. Upon a change of the status, the Graph
node generates a new aggregated descriptor, which is forwarded to the respon-
sible layer's Exchange, which has the role to notify the change event to external
entities interested in the update (
free → busy
busy → free
,
).
Results. The proposed architecture has been tested, using the testbed described
above, by varying the inter-arrival time of each incoming raw data from 1 message
per second, up to 100 messages per second. The evaluation consists in assessing
the performance of (i) the acquisition stage and (ii) computation stage. First,
performance evaluation has been made measuring the time period between points
in time when data objects are sent from a data generator to the corresponding
acquisition interface, and a point in time when the object is enriched by normal-
ization nodes, thus becoming available for the first processing Core Node. The
results are shown in Fig. 8 (a). The acquisition time is slightly increasing but it
is around 15 ms at all considered rates.
The second performance evaluation has been carried out by measuring the
time (dimension: [ms]) between the instant in which enriched data become ready
for processing activities, and the time when the message ends its Graph Frame-
work routes, becoming available for external consumers/customers. The results,
shown Fig. 8 (b), have been calculated using the following expression:
T processing freq = T out − T in i =1 graph process i
N −
1
Performance results were calculated by subtracting the processing time of
all Core and Application Nodes, in order to consider only the effective over-
head introduced by the architecture, and without considering implementation-
specific times. Finally, these times have been normalized over the number of
computational nodes, in order to obtain the per-node overhead introduced by
 
Search WWH ::




Custom Search