Closed KayodeBakker closed 1 year ago
Ik zal nog meer casussen aanleveren ter illustratie.
Ingediend bij BRKBevragen@kadaster.nl
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.
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.
@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:
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.
@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.
@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.
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
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![Langdurige bevraging BRK API productie censored](https://user-images.githubusercontent.com/47184630/177749733-1276b3f1-8b42-4b94-ad55-ad44c88cae57.png)
Screenshot is hier en daar afgeschermd aangezien het gaat om productie data maar ook om de API Key en thumbprint van een bepaald organisatie.