# Dynamic Linked Data: A SPARQL Event Processing Architecture
## 5 Application Design Pattern
### Experimental Evaluation and Preliminary Results  
This section provides some preliminary results of the evaluation of the SEPA baseline implementation ([[https://github.com/arces-wot/SEPA](https://github.com/arces-wot/SEPA)]([https://github.com/arces-wot/SEPA](https://github.com/arces-wot/SEPA))) If on the one hand, a complete performance analysis like the one presented in [22] is out of scope, on the other hand, to provide evidence regarding the feasibility of the proposed architecture, some experiments have been done. The experiments are based on the two previously-presented examples. The SEPA broker here considered implements a naive subscription algorithm (i.e., on each update, all the subscriptions are evaluated and the results of the queries compared to the previous ones): the results represent a lower bound of the performance that could be achieved (e.g., a significant speed-up would be obtained by implementing smarter algorithms and approaches like the one presented in [11; 22; 53]). All the experiments have been run on the following configuration: (i) a server (Ubuntu 15.04, Intel(R) Xeon(R) CPU E5-2430 v2 @ 2.50 GHz, 64 GB RAM) hosting the SEPA broker and the Virtuoso Open Source SPARQL endpoint; (ii) a server (Ubuntu 16.04.2 LTS, QEMU Virtual CPU version (cpu64-rhel6) @ 2.2 GHz, 1 GB RAM) hosting the client applications. The initial two experiments refer to the chat example. The first one aims at evaluating the overhead introduce by the SEPA broker on the underpinning SPARQL endpoint. A client performs the updates and queries used by the chat application (see Listing 16) in the same order shown in Figure 8. In particular, the client issues 10 SEND updates, followed by 10 SENT queries, 10 SET_RECEIVED updates, 10 RECEIVED queries and 10 REMOVE updates. The time spent by the broker to handle each request has been sampled along with the time required by the SPARQL endpoint to perform each single SPARQL request (i.e., update or query). As shown in Figure 10, in this experiment, the SEPA broker introduces an almost negligible overhead (i.e., 1.5%) to the update and query processing. The second experiment provides the reader with an overview of the update time and the latency of notifications. It consists of a client sending to itself a stream of 100 messages. Messages are sent without any break, and each message produces the sequence of notifications and updates shown in Figure 8 (i.e., (1) SEND update; (2) SENT notification; (3) SET RECEIVED update; (4) RECEIVED notification; (5) REMOVE update). As shown in Figure 11, the update time is almost limited by the SPARQL endpoint update time (attested around 50--100 ms, as shown in Figure 10). Figure 12 gives a first impression of the notification latency that can be provided by a SEPA broker. In this simple experiment, a notification is sent to a client with a latency of less then 60 ms. The last experiment refers to the MQTT monitoring example. The system has been deployed and run for more than 45 days. A screenshot of the Web application developed to monitor the sensor data is shown in Figure 13. Some preliminary dependability indicators (see Table 1) have been collected through a JMX console (see Figure 14). This experiment demonstrates the feasibility of the proposed approach and provides an indication of the level of reliability granted by the baseline SEPA implementation. \begin{table}
\begin{tabular}{c c} \hline \hline Up-time & \textgreater{}45 days \\ Processed requests & \textgreater{}30 M \\ Maximum active subscriptions & 5 \\ \hline SPARQL endpoint query average time & 28 ms \\ SPARQL endpoint update average time & 26 ms \\ \hline SEPA broker update processing average time & 55 ms \\ SPU manager processing average time & 30 ms \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Some preliminary dependability indicators of the SEPA baseline implementation with reference to the MQTT monitoring application. Figure 10: Analysis of the overhead introduce by the SEPA broker on the processing of updates and queries.