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


Warning message

You can't delete this newsletter because it has not been sent to all its subscribers.

Test Case Title

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


Assessing performance of smart city API and knowledge base

Assessing performance of City Dashboard

Assessing performance of Developer Dashboards


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.




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:
  • 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.
  • Click on url

    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)


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:


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://
    2. Authentication: username: guest, Password: guest
    3. Example on Twitter Data:
  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.