Percelen opzoeken is erg traag

Datasets BRK
#1

Namens de Gasunie hebben we de BRK-API geïmplementeerd om perceeldata op te halen en inzichtelijk te maken. We doen requests waarbij coördinaten meegegeven worden, waar het bijbehorende perceel voor getoond moet worden. Deze requests duren momenteel vaak rond de 55 seconden om afgehandeld te worden, en leveren af en toe ook een 504 Gateway Timeout op. We doen bijvoorbeeld het volgende request:

PUT https://brk.basisregistraties.overheid.nl/api/v1/perceel?page=1&pageSize=20

{
    "geometry": {
        "contains": {
            "coordinates": [
                6.5239235758781,
                53.2193064489
            ],
            "type": "Point"
        }
    }
}

Een voorbeeld van hoe deze gebruikt wordt:

Inzoomen kan op de kaart, tot percelen getoond worden. Deze kan je aanklikken. Daarna wordt de data van het perceel op die coördinaten opgevraagd (wat tot bovenstaande query leidt).

Na dit incident, en de problemen die er eerder al zijn geweest met de backwards-incompatible changes in de v1 API, en de downtime een tijdje terug door problemen op jullie productie database-server, heeft onze klant gevraagd of we hier samen met jullie naar zouden kunnen kijken. Is er iets dat wij, of jullie, kunnen doen om de snelheid en stabiliteit van de API te verbeteren, en te garanderen? Een response-time van 55 seconden blijven eindgebruikers niet erg graag op wachten.

Als er een andere, of betere, manier is waarop wij de API kunnen implementeren zodat het weer snel werkt horen we het ook graag.

#2

Het team heeft even gekeken of we het probleem dat jullie melden kunnen reproduceren en dat lukt. We zien echter wel twee zaken naar boven komen:

  • algemene performance problemen met geoqueries. Deze hangen samen met onze database, hiervoor zien we op de hele kort termijn geen mogelijkheden zien om deze performance te verbeteren. De echte versnelling verwachten we als wij overstappen op een nieuwe database, de verwachting is echter dat we dit op zijn vroegst in het 1e kwartaal van 2019 gaan doen.
  • timeouts en queries die langer dan ongeveer 15 seconden duren zien we pas sinds een aantal dagen en we zijn aan het onderzoeken waar dit probleem vandaan komt. Voor zover we nu kunnen nagaan ligt dit niet aan onze achterliggende database, we zijn dit nu verder aan het analyseren.

Julie kunnen zelf niets doen om de snelheid te verbeteren. Het team gaf nog wel als tip om de contains operatie te vervangen door een intersects, en als je voorbereid wilt zijn op de toekomst zou je ipv het PUT endpoint nog over kunnen stappen naar het POST endpoint.

#3

Bedankt voor jullie snelle antwoord en onderzoek!

Jammer dat we hier nu niets aan kunnen doen, maar ik begrijp ook dat dit niet met een druk op een knop verholpen is. We zullen kijken of we de punten die je aangeeft kunnen oppakken.

Mocht er iets komen uit het onderzoek naar de timeouts en queries van langer dan 15 seconden, zouden we hier dan een update van kunnen ontvangen? Ook als blijkt dat er (voor nu) niets aan te doen valt zou ik het fijn vinden om dat te horen, dan weten we waar we aan toe zijn :slight_smile:

#4

Zodra we een beeld hebben wat er precies aan de hand is en wanneer we dat op kunnen lossen geven we even een update.

#5

We hebben onze productie database nu een week extra in de gaten gehouden en geen (extreme) performance problemen meer gezien.

Het incident van vorige week waarbij de APIs regelmatig geheel onbereikbaar waren, lijkt een samenloop te zijn geweest van een probleem met het netwerk en routering binnen het Kadaster en het uit het geheugen lopen van de database. De database en de machine waar deze op draait zijn herstart en draaien sindsdien weer zoals verwacht. Binnenkort zullen we de database nog iets meer geheugen toekennen om dit soort problemen in de toekomst te voorkomen. De netwerkissues waren een losstaand incident dat binnen een paar uur verholpen was.

Zodra we wijzigingen aanbrengen die een impact op de performance hebben (zowel positief als negatief), komt er weer een update.

#6

Top! Ik zie dat de API nu inderdaad weer zoals voorheen reageert. Bedankt voor jullie onderzoek en updates hierover!