Download as a PDF

64
System Evaluation
5
10
2
10
4
3
10
Delay [ms]
Delay [ms]
10
2
10
1
0
10
t1
t3
t4
t5
−2
10
10
0
10
−4
1K
2K
3K 4K 5K 6K 7K
Load [Messages / s]
8K
(a)
9K 10K
10
1K 2K 3K 4K 5K 6K 7K 8K 9K
Load [Messages / s]
(b)
Figure 5.7: Delays with high load: a) Total delay (tC ), b) Delays introduced by different steps of
the processing of a message
for the experiment does not have enough computing power to handle the whole experiment.
Besides running Wisspr, the machine also has to simulate the devices and run the message
broker. One can also see that the machine is overloaded when looking at time t4 because it
measures only the time it takes to pass a message to a sender and this is a simple Java method
call. This is the reason why this time is always constant. The increase of t4 for 9000 messages
per second can clearly be attributed to an overloaded machine.
We redid the experiment and put the message broker on a separate machine. As expected
the performance of Wisspr was better: up to 9000 messages per second could be served with
a delay smaller than 100 milliseconds. Afterwards, the machine is again overloaded and the
delay grows very fast.
All in all, we can state that Wisspr introduces very small delays (less than 10 milliseconds)
for up to 7000 messages per second even when the message broker and additional processes
(like the device driver simulator) run on the same machine (see figure 5.8). Considering the
latency requirements discussed in section 3.1, this is a very good result because it is the first
precondition to support applications with relatively tight latency constraints.
5.3.3
Many Data Streams
So far, we only tested with one data stream. Now we want to evaluate the behavior when
many data streams are registered. The experiment was carried out with one machine (as in the
experiments above) and the overall delay that is introduced was measured. We only simulated
one device and each data stream got the data from this device. The data streams use no
frequency or filter, but only differ in the specified data fields. Each data stream uses a unique
combination of data fields. This is necessary to ensure that Wisspr creates all the data streams
because it is verified whether a similar data stream exists before a new data stream is registered.
We did experiments for the following numbers of data streams: 5, 10, 50, 100, 150 and 200.
Note that an incoming message from a device needs to be processed differently for each data
stream and needs to be sent to the message broker also for each data stream (since each data
stream has a separate channel on the message broker). This means that in our case the overall
number of entities that are processed by Wisspr grows linearly with the number of registered
data streams.
As a consequence, the load for this experiment was calculated by multiplying the number of