A user’s query often results in multiple calls, and each call is routed to a third-party service. Buffering therefore determines two things: how quickly a call progresses, and how much load BesluitBron places on the source platforms.
Buffering by platform
The buffer is separate for each platform. If one platform responds slowly or is temporarily unavailable, it does not hold up the other six. An emptied buffer on one platform does not affect the others.
What is cached depends on the nature of the data:
- Lists that rarely change, such as the source organisations, the committees, the party groups and the value lists on the Rechtspraak platform, are retained for a long time. These lists change on a monthly basis;
- Search results are stored for a short period. An assistant who repeats the same question during a single conversation therefore does not place a double load on the platform;
- The full text of the document is retained for as long as is reasonable, as retrieving it is the most resource-intensive operation carried out by this product.
Invalid after an upgrade
A cached response is the response as read and stored by a platform, such as a particular version of BesluitBron. A new version may ask the platform a slightly different question, or store a slightly different version of the same answer. This leaves a credible answer to a question that is no longer phrased in quite the same way. Time does not remedy this: the full text of the document is retained for weeks and thus survives multiple editions.
Each cached item therefore records which version of BesluitBron it was written by. An item that refers to a different version is discarded as soon as the need arises, and the platform is queried again. Nothing is pre-cleared. Only what is actually requested is assessed. Consequently, a restart never uses up a buffer that has just been built up.
Platform request limits
The platforms vary considerably in terms of what they can tolerate. This has been measured, not merely assumed. A limit that has not been observed is not the same as a limit that does not exist. Where the source operator has not published a limit, this has been reported as such in the findings relating to that source operator.
| Platform | Observed limit |
|---|---|
| Open Raadsinformatie | no limit observed |
| OpenBesluitvorming | 60 weighted units per minute, enforced by the platform itself |
| Tweede Kamer | no limit published and no limit observed |
| OpenTK | no strict limit; the administrator will warn users about costly searches |
| Officiële Bekendmakingen | limit on the search service |
| Rechtspraak | No limit observed on either service |
| Open Archivaris | 120 calls per minute |
BesluitBron adheres to those limits on its own end. If a platform runs out of space, a request will be queued until space becomes available again.
Waiting for a platform with a limit
If there is space available, each request is processed immediately. If there are requests queued from multiple sessions, the amount of resources used determines which one takes priority. BesluitBron keeps track of how much space each session has already used. A session that has used few resources is allocated a larger share of the space. A session that requests a lot is allocated an increasingly smaller portion the longer it continues. At OpenBesluitvorming, a session that has used 60 units receives half of what a new session receives. After 120 units, this is reduced to one-third. Two sessions that request the same amount are allocated the same amount. Within a session, the order of the calls remains the same. If there is only one session, it is allocated the entire space.
A session that is waiting is always allocated space, regardless of how much it has already used. It receives at least one call within the time it takes for the limit to be fully replenished. For OpenBesluitvorming, this is one query per minute. If there are more sessions waiting than can be accommodated within that time, the session that has been waiting the longest is prioritised. A request that uses up more than the entire quota is also processed; it will then use up the entire quota.
BesluitBron forgets the usage data for a session thirty minutes after its last call.
This applies to the platforms for which BesluitBron itself tracks a limit: Officiële Bekendmakingen, Open Archivaris, OpenBesluitvorming and Rechtspraak. The search page and BesluitBron’s own maintenance activities, such as retrieving the Laadstatus, count together as a single session. For these, usage is not counted, as they represent a large number of visitors at the same time.
This applies from version 1.4.6 onwards. Up to and including version 1.4.5, a queued call was not assigned a place in the queue. A session could therefore end up behind all the calls in a busy session. In a simulated test with the limit set to OpenBesluitvorming, a second session waited up to 106 seconds for a single search query. From version 1.4.6 onwards, this was reduced to less than three seconds in the same test. Furthermore, up to and including version 1.4.5, BesluitBron would sometimes let a request through during periods of high traffic without counting it. This meant it could send more requests than the limit allowed.
How often a client may call BesluitBron
The limits set out above protect the source platforms. A second limit protects BesluitBron itself. The MCP addresses do not require authentication, so there is a rate limit on the requests a client sends to BesluitBron. Without this limit, a single client flooding the system with requests could bring down the entire service, including those parts with which that client has nothing to do.
There are three limits, and a request passes all three of them:
- a limit for the entire process, because a flood of requests affects the whole service, not just a single address;
- one limit per connector, so that pressure on one connector does not displace the other;
- one limit per session, and one limit per client address before a session begins, so that a single client does not use up all the space.
A client that exceeds a limit will receive an HTTP 429 error with a ‘Retry-After’. This is the number of seconds the client must wait before retrying. The limits are set generously and do not affect normal use. An administrator can increase them at BesluitBron:McpRateLimit for an installation with a large number of concurrent clients. See Uitrol en Beheer.
What a reader notices about this
An initial query on a topic takes longer than a follow-up query on the same topic. A query that requires the full text of a document takes longer than one that only needs the titles. A query covering all 331 sources at once takes longer than a query covering a single municipality. Immediately after an upgrade of BesluitBron, an initial query again takes longer, as the buffer from the previous version is no longer used.
If that difference is significant enough to influence the conversation, it will be noted in the tool section. The assistant can then opt for the cheaper option if it also provides the answer.