AKSW/building-navigator

Improve perfomance with too many query variables

Closed this issue · 6 comments

simeonackermann commented

The current query of places is very slow. It can improved by using less query variables.

e.g. the query:

PREFIX lePlace:<http://le-online.de/place/>
PREFIX leNs:<http://le-online.de/ontology/place/ns#>
SELECT * FROM NAMED <http://example.org/> WHERE {
    GRAPH ?g {
        ?uri leNs:placeName ?name .
        ?uri leNs:address ?address .
        ?uri leNs:lift-available ?liftAvailable .
        ?uri leNs:lift-liftWithWheelChairSupportAvailable ?liftWithWheelChairSupportAvailable .
        ?uri leNs:parkingLot-lotsForDisabledPeopleAvailable ?parkingLotsForDisabledPeopleAvailable .
        ?uri leNs:toilets-toiletForDisabledPeopleAvailable ?toiletForDisabledPeopleAvailable .
        ?uri leNs:lat ?lat .
        ?uri leNs:lng ?lng .
        ?uri leNs:note ?note .
        ?uri leNs:category ?category .
} } LIMIT 10

needs about 15000 ms. The query:

PREFIX lePlace:<http://le-online.de/place/>
PREFIX leNs:<http://le-online.de/ontology/place/ns#>
SELECT * FROM NAMED <http://example.org/> WHERE {
    GRAPH ?g {
        ?uri leNs:placeName ?name .
        ?uri leNs:address ?address .
        ?uri leNs:lift-available ?liftAvailable .
        ?uri leNs:lift-liftWithWheelChairSupportAvailable ?liftWithWheelChairSupportAvailable .
        ?uri leNs:parkingLot-lotsForDisabledPeopleAvailable ?parkingLotsForDisabledPeopleAvailable .
        ?uri leNs:toilets-toiletForDisabledPeopleAvailable ?toiletForDisabledPeopleAvailable .
} } LIMIT 10

only 300 ms.

Is this a normal behavior?

We should load additional properties (like note) only if they are used in frontend. E.g. load them later via ajax.

simeonackermann commented

Improved in cfb250d, loading notes and category only if first toggle details

k00ni commented

👍

Loading long shouldn't be normal behavior, but i find your solution good. Is it possible to render and build the UI and after everything is "ready", you load all remaining information anyways? Or is that to much stuff to store on the client, regardless of its usage?

simeonackermann commented

Closed because new behavior with Virtuoso and dynamically loading.

simeonackermann commented

Also with Virtuoso I've problems with the perfomance. E.g. the query for fetch max 30 places with its properties and elevator accessibility info needs about 3 - 7 seconds.

PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX geo: <http://www.w3.org/2003/01/geo/>
PREFIX plcOnt: <http://behindertenverband-leipzig.de/place-ontology/>
PREFIX elvOnt: <https://github.com/AKSW/leds-asp-f-ontologies/blob/master/ontologies/elevator/ontology.ttl#>
PREFIX unitMeas: <https://github.com/AKSW/leds-asp-f-ontologies/blob/master/ontologies/unit-and-measurements/ontology.ttl#>
PREFIX lePlace: <http://le-online.de/place/>
PREFIX leNs: <http://le-online.de/ontology/place/ns#>

SELECT ?uri ?id ?title ?long AS ?lng ?lat
    ?elevatorCabineIsAvailable ?elevatorCabineLength ?elevatorCabineWidth ?elevatorDoorWidth ?elevatorCabineHighestButtonOutside ?elevatorCabineHighestButtonInside
FROM <http://building-navigator.de/>
WHERE {
    ?uri rdf:type plcOnt:place ;
        plcOnt:ID ?id ;
        dc:title ?title ;
        geo:long ?long ;
        geo:lat ?lat ;
        elvOnt:hasElevatorCabine ?elevatorCabineUri .
    ?elevatorCabineUri elvOnt:isAvailable ?elevatorCabineIsAvailable ;
        unitMeas:length ?elevatorCabineLengthUri ;
        unitMeas:width ?elevatorCabineWidthUri ;
        elvOnt:hasDoorWidth ?elevatorDoorWidthUri ;
        elvOnt:highestDistanceOfControlPanelButtonFromGroundInside ?elevatorCabineHighestButtonOutsideUri ;
        elvOnt:highestDistanceOfControlPanelButtonFromGroundOutside ?elevatorCabineHighestButtonInsideUri .
    ?elevatorCabineLengthUri unitMeas:cm ?elevatorCabineLength . 
    ?elevatorCabineWidthUri unitMeas:cm ?elevatorCabineWidth .
    ?elevatorDoorWidthUri unitMeas:cm ?elevatorDoorWidth .
    ?elevatorCabineHighestButtonOutsideUri unitMeas:cm ?elevatorCabineHighestButtonOutside .
    ?elevatorCabineHighestButtonInsideUri unitMeas:cm ?elevatorCabineHighestButtonInside .
}
LIMIT 30
simeonackermann commented

Its strange.
I added the elevator information as property to each place to avoid joins, and get good perfomance. The query:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX geo: <http://www.w3.org/2003/01/geo/>
PREFIX plcOnt: <http://behindertenverband-leipzig.de/place-ontology/>

SELECT ?uri ?id ?category ?title ?long AS ?lng ?lat
    ?elevatorCabineIsAvailable ?elevatorIsWheelchairAccessible
FROM <http://building-navigator.de/>
WHERE {
    ?uri rdf:type plcOnt:place .
    ?uri plcOnt:ID ?id .
    ?uri plcOnt:category ?category .
    ?uri plcOnt:elevatorCabineIsAvailable ?elevatorCabineIsAvailable .
    ?uri plcOnt:elevatorIsWheelchairAccessible ?elevatorIsWheelchairAccessible .
    ?uri dc:title ?title .
    ?uri geo:long ?long .
    ?uri geo:lat ?lat .
}
LIMIT 30

But with just some more query variables its again very bad, e.g. add to query:

    ?uri <http://schema.org/streetAddress> ?streetAddress .
    ?uri <http://schema.org/postalCode> ?postalCode .
    ?uri <http://schema.org/addressLocality> ?addressLocality .
simeonackermann commented

Close with usage of #16