**6. Results**

The prototype of APERTO5.0 constitutes the backbone of services where the different partners constellating the tourism path and tourists receive and provide information also exploiting ad-hoc developed mobile-oriented applications.

Given the huge and ever-increasing number of data sources that APERTO5.0 is required to handle we are interested to present here two main quite common and potentially critical processes: (1) The action of gathering and querying data across complex and distributed topologies of sources; and (2) the processing and integration of cases to demonstrate the ability of proposed platform of gathering and process data and services in order to be re-exposed. We concentrate on these two specific functions, since the huge quantity of data produced by geographically distant places in the "Francigena way" requires a powerful and fast gathering processing phases, so as to maximize the value of the obtained information.

The tests are organized along the two major problems highlighted: with the first test-bed section aiming in proving the ability of Zenoh in supporting presented architecture in the phases of receiving and querying of data and with the second section with the goal of confirming the capacity of the chosen platform in adapting and processing incoming information. Afterward, we confirm the introduction of a FaaS platform as an essential part able to address the extreme variability in tourism service load while also facilitating the fast development of connectors to take on the Prod-Con heterogeneity.

The tests of the first testbed section are deployed on an infrastructure composed of 5 nodes equipped with an Intel(R) Core (TM) i5-3470 CPU running at 3.20 GHz and 8 GB of RAM each. All the tests of the second testbed section have been conducted on a physical infrastructure composed of five virtual machines each equipped with 8 vCores, 32 GB vRAM, and 150 GB data SSD.

### *6.1. Social Sensing Data Gathering*

Infrastructure topologies interconnecting prosumers in the context of pilgrims paths can assume diverse levels of complexity by traversing many networks and applicative endpoints. This complexity is further worsened by the fact that a user will consume in their experiences not only local data but potentially data distributed far away, many stages before or after the current location. For this reason, this section aims at testing the capabilities of Zenoh in supporting APERTO5.0 in both processes of receiving data through a standard Pub/Sub protocol and querying data at rest present in separate locations, with varying interconnection topologies and load. We then compare the obtained results with two often adopted technologies for data gathering, namely RabbitMQ [34] and a cascade of Envoy HTTP Reverse proxy under the same conditions [35].

In the use case of "Francigena way", one of the most challenging tasks that proposed infrastructure requested to realize is the ability to gather and retrieve data traversing arbitrary complex networks and infrastructural topologies. This happens often during social sensing action where the data coming from sensors are requested to traverse different devices like

user smartphone or Wi-Fi Access Points compared to the ability of Zenoh, RabbitMQ, and HTTP of traversing multiple hops to interrogate sources of data in the territory.

We have triggered an increasing number of requests starting from a frequency of 1 request per second and reaching 1000 requests per second. Results shown in Figure 4 highlight that in a request/reply interaction HTTP performs better when the number of hops traversed increases.

**Figure 4.** Round trip time of requests when traversing an increasing number of network hops.

We then tested the ability of the different solutions to satisfy higher rates of requests experienceable when multiple users and devices send contemporary a lot of data. We then repeat the precedent experiment in the case of 2 hops to be traversed and we sent an increasing rate of requests starting from 0 to 10,000 requests per second.

As Figure 5 shows, while HTTP forwarding realized through proxies performs better at low request rates when the rate exceeds 4000 requests per second the performance of this protocol starts to degrade with a fluctuating behavior and an RTT measured higher than once of Zenoh and RabbitMQ.

**Figure 5.** Round trip time of requests when traversing 2 hops with an increasing number of requests per second, starting from 0 up to 10,000.

We then tested the ability of RabbitMQ and Zenoh of distributing and collecting information through a typical Publish/Subscribe mechanism. This test foresees the exclusion of the HTTP Proxy and HTTP protocol does not support such type of interaction.

In particular, the third test follows the same guidelines as above to compare and verify the routing capacity and the delay introduced by the two message-oriented middlewares

in distributing a constantly increasing amount of information among multiple subscribers, when traversing infrastructural and network topologies with different complexity.

The outcome of the test shows (Figure 6) that Zenoh introduces a delay in the delivery of information lower than 3 milliseconds, even when traversing multiple intermediaries. Moreover, the pub/sub protocol implementation realized by these two solutions seems to be less influenced by the complexity of traversed topologies, with a delay variation lower than 1 millisecond.

**Figure 6.** Registered delay in publish/subscribe mechanisms when traversing an increasing number of network hops starting from direct point to point communication to three intermediaries.

In conclusion, the tests of this section justify the choice of the authors of introducing Zenoh as a middleware, to retrieve and collect information in arbitrary complex scenarios not only because of its good and more stable performance, even at elevate request rates, but also for its flexibility in supporting multiple interactions paradigms, such as request-reply and pub/sub.
