Een vraag van een gebruiker leidt vaak tot meerdere aanroepen, en elke aanroep gaat naar een dienst van een derde. Buffering bepaalt daarom twee dingen: hoe snel een gesprek verloopt, en hoe zwaar BesluitBron de bronplatformen belast.
Buffering per platform
De buffer is per platform gescheiden. Een platform dat traag antwoordt of tijdelijk niet bereikbaar is, houdt de andere zes niet op. Een leeggemaakte buffer van het ene platform raakt de andere niet.
Wat er wordt gebufferd, hangt af van de aard van de gegevens:
- Lijsten die zelden wijzigen, zoals de bronorganisaties, de commissies, de fracties en de waardelijsten van het platform Rechtspraak, worden lang bewaard. Deze lijsten wijzigen in de orde van maanden;
- Zoekresultaten worden kort bewaard. Een assistent die dezelfde vraag in één gesprek herhaalt, belast het platform daardoor niet twee keer;
- Volledige documenttekst wordt bewaard zolang dat verantwoord is, want het ophalen ervan is de duurste bewerking die dit product uitvoert.
Ongeldig na een upgrade
Een gebufferd antwoord is het antwoord van een platform zoals een bepaalde versie van BesluitBron het heeft gelezen en bewaard. Een nieuwe versie kan iets anders vragen aan het platform, of iets anders bewaren van hetzelfde antwoord. Er ligt dan een geloofwaardig antwoord op een vraag die niet meer zo wordt gesteld. Tijd repareert dat niet: volledige documenttekst wordt weken bewaard en overleeft daarmee meerdere uitgaven.
Elk gebufferd item legt daarom vast door welke versie van BesluitBron het is geschreven. Een item dat een andere versie noemt, wordt weggegooid op het moment dat er iets om vraagt, en het platform wordt opnieuw bevraagd. Er wordt niets vooraf geschoond. Alleen wat daadwerkelijk wordt opgevraagd, wordt beoordeeld. Een herstart kost daardoor nooit een buffer die zojuist is opgebouwd.
Verzoeklimieten van de platformen
De platformen verschillen sterk in wat zij verdragen. Dat is gemeten en niet aangenomen. Een niet waargenomen limiet is geen afwezige limiet. Waar de bronhouder geen limiet publiceert, is dat als bevinding bij die bronhouder gemeld.
| Platform | Waargenomen limiet |
|---|---|
| Open Raadsinformatie | geen limiet waargenomen |
| OpenBesluitvorming | 60 gewogen eenheden per minuut, door het platform zelf afgedwongen |
| Tweede Kamer | geen limiet gepubliceerd en geen limiet waargenomen |
| OpenTK | geen harde limiet; de beheerder waarschuwt zelf voor dure zoekopdrachten |
| Officiële Bekendmakingen | limiet aanwezig op de zoekdienst |
| Rechtspraak | geen limiet waargenomen op beide diensten |
| Open Archivaris | 120 aanroepen per minuut |
BesluitBron houdt zich aan die limieten aan de eigen kant. Is de ruimte bij een platform op, dan wacht een aanroep tot er weer ruimte is.
Wachten op een platform met een limiet
Is er ruimte, dan gaat elke aanroep direct door. Wachten er aanroepen van meerdere sessies, dan bepaalt het verbruik wie voorgaat. BesluitBron houdt per sessie bij hoeveel ruimte zij al heeft gebruikt. Een sessie die weinig heeft gevraagd, krijgt een groter deel van de ruimte. Een sessie die veel vraagt, krijgt een steeds kleiner deel naarmate zij langer doorgaat. Bij OpenBesluitvorming krijgt een sessie die 60 eenheden heeft gebruikt, de helft van wat een nieuwe sessie krijgt. Na 120 eenheden is dat een derde. Twee sessies die evenveel vragen, krijgen evenveel. Binnen een sessie blijft de volgorde van de aanroepen gelijk. Is er maar één sessie, dan krijgt die de hele ruimte.
Een sessie die wacht, krijgt altijd ruimte, hoeveel zij ook al heeft gebruikt. Zij krijgt minstens één aanroep in de tijd die de limiet nodig heeft om helemaal bij te vullen. Bij OpenBesluitvorming is dat één zoekopdracht per minuut. Wachten er meer sessies dan er in die tijd aanroepen passen, dan gaat de sessie voor die het langst wacht. Een aanroep die meer kost dan de hele limiet, gaat ook door. Hij kost dan de hele limiet.
BesluitBron vergeet het verbruik van een sessie dertig minuten na haar laatste aanroep.
Dit geldt voor de platformen waarvoor BesluitBron zelf een limiet bijhoudt: Officiële Bekendmakingen, Open Archivaris, OpenBesluitvorming en Rechtspraak. De zoekpagina en het eigen onderhoud van BesluitBron, zoals het ophalen van de Laadstatus, tellen samen als één sessie. Voor hen telt het verbruik niet mee, want zij staan voor veel bezoekers tegelijk.
Dit geldt vanaf versie 1.4.6. Tot en met versie 1.4.5 kreeg een wachtende aanroep geen plek in een rij. Een sessie kon dan achter alle aanroepen van een drukke sessie terechtkomen. In een nagebootste meting met de limiet van OpenBesluitvorming wachtte een tweede sessie tot 106 seconden op één zoekopdracht. Vanaf 1.4.6 was dat in dezelfde meting minder dan drie seconden. Ook liet BesluitBron tot en met 1.4.5 bij drukte soms een aanroep door zonder die mee te tellen. Zo kon het meer aanroepen sturen dan de limiet toestond.
Hoe vaak een client BesluitBron mag aanroepen
De limieten hierboven beschermen de bronplatformen. Een tweede grens beschermt BesluitBron zelf. De MCP-adressen kennen geen authenticatie, dus staat er een snelheidsgrens op de verzoeken die een client naar BesluitBron stuurt. Zonder die grens legt één client met een stortvloed aan verzoeken de hele dienst plat, ook de onderdelen waar die client niets mee te maken heeft.
Er zijn drie grenzen, en een verzoek passeert ze alle drie:
- een grens voor het hele proces, want een stortvloed raakt de hele dienst en niet één adres;
- een grens per connector, zodat drukte op de ene connector de andere niet verdringt;
- een grens per sessie, en vóór een sessie bestaat per client-adres, zodat één client de ruimte niet alleen opmaakt.
Een client die een grens overschrijdt, krijgt HTTP 429 met een Retry-After. Dat is het aantal seconden om te wachten voordat de client het opnieuw probeert. De grenzen staan ruim en raken normaal gebruik niet. Een beheerder verhoogt ze onder BesluitBron:McpRateLimit voor een installatie met veel gelijktijdige clients. Zie Uitrol en Beheer.
Wat een lezer hiervan merkt
Een eerste vraag over een onderwerp duurt langer dan een vervolgvraag over hetzelfde onderwerp. Een vraag die volledige documenttekst nodig heeft, duurt langer dan een vraag die aan de titels genoeg heeft. Een vraag over alle 331 bronnen tegelijk duurt langer dan een vraag over één gemeente. Direct na een upgrade van BesluitBron duurt een eerste vraag opnieuw langer, want de buffer van de vorige versie wordt dan niet meer gebruikt.
Is dat verschil groot genoeg om het gesprek te sturen, dan staat het bij het gereedschap vermeld. De assistent kan dan de goedkope weg kiezen wanneer die het antwoord ook geeft.