Performance in productie niet acceptabel

[KayodeBakker]

Beschrijf de bug De performance van bevragingen in productie lijken niet acceptabel. Grotendeels lijkt dit in geval te zijn van appartementsrechten.

To Reproduce Stappen om de bug te reproduceren

1. Ga naar /kadastraalonroerendezaken?kadastraleAanduidingMetGemeentecode=GNG00 P 1708 A594&fields=identificatie,domein,indicatieVervallen,begrenzingPerceel,perceelnummerRotatie,plaatscoordinaten,koopsom,toelichtingBewaarder,type,aardCultuurBebouwd,aardCultuurOnbebouwd,kadastraleAanduiding,kadastraleGrootte,perceelnummerVerschuiving,adressen,privaatrechtelijkeBeperkingIdentificaties,hypotheekIdentificaties,beslagIdentificaties,isOvergegaanIn,isOntstaanUit,bijbehorendeGrondpercelen,bijbehorendeAppartementsrechten,isVermeldInStukdeelIdentificaties,stukIdentificaties,gesplitstZakelijkRecht,indicatieSluimerend
2. Wacht 7 seconden bij de eerste request (vervolg requests kunnen 2 seconden zijn of een lange 1 seconden, maar dit is vast vanwege caching)
3. Zie resultaat

Verwacht gedrag Bevragingen, met name gene welke weinig resultaten hoort te leveren, dienen snel te performen. Bij groot voorkeur altijd onder 1 seconde en met uitzondering van grote responses een langere wachttijd.

Hieronder een screenshot van een voorbeeld casus met looptijd in powershell.

Screenshots

Screenshot is hier en daar afgeschermd aangezien het gaat om productie data maar ook om de API Key en thumbprint van een bepaald organisatie.

[KayodeBakker]

Ik zal nog meer casussen aanleveren ter illustratie.

[CathyDingemanse]

Ingediend bij BRKBevragen@kadaster.nl

[KayodeBakker]

Waarde	Responsetijd	Perceel/Appartementsrecht
HLD01 G 4852	330ms	Perceel
RMD00 D 5661 A2	460ms	Appartementsrecht
APD02 AC 6029	760ms	Perceel
GNG01 P 1708 A593	5442ms	Appartementsrecht
GNG01 P 1708 A594	3495ms	Appartementsrecht
59020170810594	6770ms	Appartementsrecht
59020170810593	8478ms	Appartementsrecht
GNG01 P 1708 A219	4891ms	Appartementsrecht
59020170810219	8504ms	Appartementsrecht
GNG01 P 1309	14379ms	Perceel
59020130970000	14460ms	Perceel
VLO00 I 6833	2086ms	Perceel
37530683370000	1201ms	Perceel
VLO00 I 6837 A114	1336ms	Appartementsrecht
37530683710114	1345ms	Appartementsrecht

Het is belangrijk om te noemen dat al deze voorbeelden zijn geprobeerd met beiden fields als geen fields en het verschil is verwaarloosbaar.

De response tijden lijken soms ook te schommelen. Initieel dachten we dat dit te maken had met enig vorm van caching, maar soms wilde een response ook van 5000ms terug naar 7500ms gaan waar de eerste response 8500ms was.

Ook opvallend is dat de responses hierboven een hoop sneller zijn dan in acceptatie wat gek is aangezien acceptatie hoort productie te weerspiegelen maar wellicht met een kleinere testset. Zelfs zou de verwachting moeten zijn dat deze testset niet incomplete objecten heeft ten op zichten van productie. Als een casus wordt geïntroduceerd in test die in productie zeg 6 relaties heeft dan verwachten we al deze relaties ook in test.

Het lijkt erop dat specifieke gebieden in Nederland met name voor issues zorgen, maar dat zou in theorie niet anders moeten functioneren of je nou in Groningen of Hoek van Holland zit.

[FerryDeJong]

Allereerst sorry voor het trage antwoord, ondanks de vakantieperiode had dat sneller gemoeten.

Het kan kloppen dat de reactietijd van deze services meerdere seconden kunnen duren.

De responstijd is van een aantal factoren afhankelijk, voornamelijk de complexiteit van de objecten speelt daarin een belangrijke rol. Grotere/complexere responses duren langer in alle stappen tot de eindgebruiker. (die complexiteit is niet altijd zichtbaar in het resultaat wat de gebruiker ontvangt)

(er is geen relatie met de geografische ligging van objecten, anders dan dat in stedelijke gebieden vaak complexere objecten te vinden zijn) Het kan daardoor ook kloppen dat appartementsrechten opvragen gemiddeld iets langer duurt dan het opvragen van grondpercelen.

Daarnaast kan de responstijd verschillen per moment, op momenten dat de systemen door meer gebruikers worden bevraagd kan het zijn dat de respons iets langer duurt.

Uiteraard streven wij ernaar om de antwoorden zo snel mogelijk te verstrekken, maar responstijden onder de seconde voor alle objecten is op dit moment geen haalbaar streven.

Wij waarderen het signaal over de performance, maar op dit moment is bovenstaande voor ons acceptabel en verwacht ik niet dat op korte termijn grote veranderingen zullen plaatsvinden in deze responstijden.

[KayodeBakker]

@FerryDeJong Bedankt voor de reactie!

Nu heb ik begrip voor dat er infrastructurele factoren zijn en dat er complexiteit bestaat, maar met jouw conclusie ben ik het zeker niet eens. Zeggen dat dit acceptabel is, is dan vervolgens beweren dat de gebruiker er maar mee moet dealen. Alles wat de gebruiker probeert is een bevraging te doen en de complexiteit van een bron, die responsetijden beïnvloed, hoort niet hun probleem te worden. Afnemers moeten vervolgens dan weer aan eigen klanten verkopen dat zij traag zijn omdat het Kadaster factoren heeft die de response beinvloeden.

Als we even casussen achterwegen laten zoals 'GNG01 P 1309' uit mijn testresultaten, welke bijna 15 seconden erover doet en toegegeven veel data retourneert, en alleen focust op zeg 'GNG01 P 1708 A594' welke 3.5 seconden erover doet (5 zelfs bij het zojuist nogmaals uitproberen) dan kan dit verre van acceptabel zijn. De casus 'GNG01 P 1708 A594' geeft namelijk enkel en alleen terug 1 kad onroerende zaak, 1 adres, 1 privaatrechtelijke beperking identificatie en verder 2 bijbehorende grondpercelen en 1 isOntstaanUit. Dat is een kleine response op een simpel appartementementsrecht. Alles boven de 1 seconde zou hier onacceptabel moeten zijn.

Het is overigens ook zeer opvallend dat de casus 'GNG01 P 1708 A594' nu 5 seconden erover doet met de klein beetje data die erin zit en dat een casus uit Roermond welke ook een appartementsrecht is er een halve seconden over doet. Deze casus 'RMD00 D 5661 A2' heeft namelijk een response met dezelfde formaat als de voorbeeld uit Groningen met uitzondering van het ontbreken van de privaatrechtelijke beperking identificatie en slechts 1 bijbehorende grondperceel minder. De response geformatteerd is zelfs maar 6 regels korter voor een tijdsverschil van 4.5 seconden.

Concluderend ben ik het niet eens met jouw conclusie om de volgende redenen:

• Een afnemer zou niet verantwoordelijk moeten zijn voor issues vanuit de bron waar ze aan koppelen met name als dit met responsetijden te maken heeft.
• Er lijkt zeker wel onder water iets niet te kloppen (geografisch of niet, maar wellicht verschillende bronsystemen) aangezien een casus uit Groningen er 3.5 tot 4.5 seconden langer over doet dan een Roermond casus die vergelijkbare data retourneert.
• Responses die klein zijn qua data zijn nooit acceptabel als ze boven 1 seconde aan wachttijd hebben.
• Responsetijden kunnen inderdaad verschillen op verschillende momenten, echter waren mijn testresultaten in het weekend en in de ochtend van een maandag bij elkaar geraapt. Daarmee kan er worden geconcludeerd dat er niet sprake is van momentopnames door drukte.
  • Tevens heb ik zojuist nog de Groningen en Roermond casussen gebruikt en de Groningen casus is 1.5 seconden langzamer geworden en de Roermond casus 100 miliseconden langzamer. Dat maakt drie momenten (weekend, maandagochtend, dinsdagavond) waar de responses vergelijkbaar zijn en sowieso nooit beter dan is genoemd in de testresultaten.

Zou je kunnen toelichten wat er tot zo ver is gedaan om naar dit vraagstuk te kijken? De conclusies die je trekt, lijken niet met de realiteit overeen te komen en mijn tegenargumenten hadden jullie zelf kunnen achterhalen door simpelweg mijn testgevallen te beoordelen. Dit wekt namelijk de indruk op dat er nog vrij weinig naar gekeken is.

[CathyDingemanse]

@FerryDeJong de geconstateerde performance is niet acceptabel omdat deze niet voldoet aan de afgesproken eisen aan de performance in de SLA. Hierin staat dat meer dan 95% van de bevragingen in minder dan 2000 milliseconde wordt beantwoord.

Ik wil je vragen om opvolging geven aan de gemaakte afspraken.

[FerryDeJong]

@KayodeBakker Bedankt voor je antwoord. Dat dezelfde objecten op verschillende momenten ongeveer dezelfde performance leveren is gedrag wat wij verwachten. Een object wat langer duurt zal bij iedere opvraging meer tijd kosten, daarin kunnen zoals je aangeeft kleine verschillen zitten van moment tot moment.

De vergelijking tussen de objecten in Groningen en Roermond doe jij op basis van de inhoud die jij ontvangt, echter kan je daarin niet zien welke informatie daaruit door ons gefilterd is. De verschillende objecten kunnen wel degelijk verschillende omvang hebben en daardoor langer duren. In de vergelijking die jij doet is dat niet te zien en ik begrijp daardoor wel jouw verbazing. Zoals al aangegeven is er geen verschil in responstijden op basis van de geografische ligging (de informatie staat allemaal op dezelfde plek opgeslagen) wel als gevolg van de inhoud.

Om een goed beeld te geven van de respons over het geheel heb ik nogmaals even naar de performance gekeken ook voor specifiek de BRK API. Wij monitoren dit continue voor alle diensten die gebruik maken van deze infrastructuur en zien daarin een performance die voor ons acceptabel is.

De gemiddelde responstijd over alle bevragingen van de BRK API van de afgelopen 30 dagen is (gemeten over ruim 44.000 hits) komt uit op 710,7ms.

Gemiddeld is de responstijd dus ruim onder de seconde. In dat gemiddelde ook de antwoorden die langer duren, en als je daarop zit te wachten is dat vervelend. Ik maak zelf genoeg gebruik van de diensten waar ik verantwoordelijk voor ben om door te hebben dat dit wachten in sommige gevallen langer duurt dan wenselijk. Er wordt continue gekeken naar de plekken waar wij dit kunnen verbeteren, maar ik verwacht niet dat op korte termijn ook de meest complexe objecten tot een responstijd onder de seconde komen.