TC10.18 - Assessing Performance of API, Knowledge Base and Dashboards

Test Case Title	TC10.18 - Assessing Performance of API, Knowledge Base and Dashboards
Goal	Assessing performance of smart city API and knowledge base Assessing performance of City Dashboard Assessing performance of Developer Dashboards
Prerequisites	Using a PC or Mobile with a web browser. Assessment of RDF store and API services. The following functionalities are available only for specific Snap4city users with specific privileges.
Expected successful result	Measures of the performances.
Steps

 

Please note that some of the following links could be accessible only for registered users.

The storage solutions to save and store data are capable to cope with large data sets, providing results in fast and reliable manner [RDFcomparison], [FGCS]. The solution is based on high performance noSQL databases: HDFS, Hbase, RDF GraphDB Virtuoso [RDFComparison]. See the access to Km4City demonstrator, and City of Florence Smart City data, running since 2 years ago, more than 1.2 million of complex new data elements per day. An assessment has been also performed and data are accessible on [FGCS].

---

Example 1: performance assessment of the Knowledge Base and smart City API

In this case, the Km4City based Knowledge Base is stored into a GraphDB as Virtuoso and it used for serving the ServiceMap, ServiceMap3D, LOG and Advanced Smart City API:

• Performance analysis of the RDF Store is reported in [RDFcomparison], in section references at the end of this document and also provided on Google Drive.
• The Km4City model has been optimized to provide results in an efficient manner for the typical queries that can be performed by:
  • Smart City applications,
  • Smart City Dashboard,
  • Data Analytics,
  • Advanced Smart City API.
• The test queries and the data for testing are accessible as described in the paper.

• For your direct test, a test of the performance can be performed posing queries on the ServiceMap visual interface modelling the whole Tuscany area. It presently contains 150 million of triples. Examples are preformed queries for several kinds of entities are reported in the sequel.
  • The number of triples in the virtuoso triple store can be retrieved using the sparql endpoint: https://toscana.km4city.org/WebAppGrafo/sparql?query=select%20count(*)%20as%20?count{?s%20?p%20?o}&format=html 
    
    The present configuration under test is based on: Virtuoso 7.2.1 with 32GB RAM and 8 CPU, hosting.
    
    You can start testing this requirement by following the sequence of actions:

• Click on url  https://servicemap.disit.org/WebAppGrafo/api/v1/tpl/bus-position/?format=json
  
  it returns a GeoJSON reply with the estimated current position of the “ATAF” buses based on the time schedule, it is performed with a complex SPARQL query over the GTFS time schedule stored in a graph of 21M triples with the time schedule for 1 year. The result is provided in about 3s (it can be checked using the Network console of the browser)

• Click on url https://servicemap.disit.org/WebAppGrafo/api/v1/location/?position=43.7741;11.2505&format=json
  
  It makes a geographic SPARQL query to search for the nearest address to a GPS position, searching over 2M geographic positions. The reply is provided in less than 1s.
• Click on url https://servicemap.disit.org/WebAppGrafo/api/v1/location/?position=43.7741;11.2505&intersectGeom=true&format=json
  
  It makes the same query as previous but additionally it checks if the position provided intersects some other geometries in the KB (green areas, restricted traffic zones, bus lines, etc.). In this case the time needed to reply is increased to about 11s (a bug of virtuoso force checking all the replies as it sometimes provides geometries that are not intersecting the position provided).
• Click on url https://servicemap.disit.org/WebAppGrafo/api/v1/?selection=43.7756;11.2490&categories=Accommodation;BusStop;SensorSite;Car_park&maxResults=10&maxDists=0.5&lang=it&format=json it search for the 10 nearest Accommodations, bus stops, sensor sites and car parks that are in 500m from a specified position, it performs three SPARQL queries, one for bus stops, one for sensors and one for other services, and it performs the same query two times one for retrieving the count of entities matching the search request and one to provide the effective data. The reply is provided in less than 3s. The time needed depends on the radius, however it does not increase very much (with a maxDists of 200Km takes about 13s).
  
  Note: the times reported were evaluated from a browser in the same network of the server, the evaluation from outside network may introduce delays due to limitations of your internet connection.

 

---

Example 2: Performance Assessment of City Dashboards

Both real-time data and ingested data from ETL and IOT processes are stored in a noSQL database. The storage adopted is based on Hbase with Phoenix. The Dashboards created by the Dashboard Builder as well as the Advanced Smart City API directly access to the data coming from IOT Brokers via the access to Hbase Phoenix. In most cases, the data are indexed and accessed via SOLR as demonstrated with the following point.

You can start testing this requirement by following the sequence of actions:

• Click on the following URL of the WEB APP or ServiceMap to get tabular data; for example for accessing to the:
  • Pollution and Pollination
  • Weather Forecast
  • Traffic Flow Data
  • Etc.
• A test of the performance can be performed: click on https://servicemap.disit.org/WebAppGrafo/api/v1/?serviceUri=http://www.disit.org/km4city/resource/CarParkCareggi&format=json
  
  it retrieves the current status of the parking, and additionally it provides the predictions and the daily parking occupation trends. The result is provided in less than 1s.
  • click on https://servicemap.disit.org/WebAppGrafo/api/v1/?serviceUri=http://www.disit.org/km4city/resource/METRO487
    
    it retrieves the current status for a traffic sensor, it takes less than 1s. click on https://servicemap.disit.org/WebAppGrafo/api/v1/?serviceUri=http://www.disit.org/km4city/resource/048017
    
    it retrieves the latest weather forecast for the Florence municipality, it takes less than 1s. click on https://servicemap.disit.org/WebAppGrafo/api/v1/?serviceUri=http://www.disit.org/km4city/resource/Bus_ataflinea_Stop_FM7004_5
    
    it provides the timetable for a bus stop for the next 24h, result is provided in less than 2s.

 

---

Example 3: Performance Assessment of Developers Dashboard

The Developed Dashboards are based on data indexed by SOLR, which have been sharded on cloud with multiple nodes. Each node presents a Zookeeper. The index is created automatically by data flowing.

The following tests are shown on two different scenarios:

1. A table based on Twitter data, of 320 Million of lines, quite complex, which present a SOLR index with 4 nodes sharded without replicas.
   1. Entry Login URL: Http://tvSOLR.disit.org
   2. Authentication: username: guest, Password: guest
   3. Example on Twitter Data: http://tvSOLR.disit.org/search/?collection=1
2. A table based on IOT/ETL data communing from sensors, about 18 Million of records, which present a SOLR index on 4 nodes shared with replicas. Which is more reliable and robust.
   1. https://devdash.snap4city.org/