Eine Anfrage eines Nutzers führt oft zu mehreren Aufrufen, und jeder Aufruf wird an einen Dienst eines Drittanbieters weitergeleitet. Die Pufferung bestimmt daher zwei Dinge: wie schnell ein Gespräch abläuft und wie stark BesluitBron die Quellplattformen belastet.
Pufferung nach Plattform
Der Puffer ist pro Plattform getrennt. Eine Plattform, die langsam reagiert oder vorübergehend nicht erreichbar ist, hält die anderen sechs nicht auf. Ein geleerter Puffer einer Plattform hat keine Auswirkungen auf die anderen.
Was gepuffert wird, hängt von der Art der Daten ab:
- Listen, die sich selten ändern, wie beispielsweise die Quellorganisationen, die Ausschüsse, die Fraktionen und die Wertelisten der Plattform „Rechtspraak“, werden langfristig aufbewahrt. Diese Listen ändern sich im Abstand von mehreren Monaten;
- Suchergebnisse werden nur kurz gespeichert. Ein Assistent, der dieselbe Frage innerhalb eines Gesprächs wiederholt, belastet die Plattform dadurch nicht zweimal;
- Der vollständige Dokumenttext wird so lange gespeichert, wie dies vertretbar ist, da das Abrufen des Textes der aufwendigste Vorgang ist, den dieses Produkt ausführt.
Nach einem Upgrade ungültig
Eine zwischengespeicherte Antwort ist die Antwort, wie sie von einer Plattform – beispielsweise einer bestimmten Version von BesluitBron – gelesen und gespeichert wurde. Eine neue Version kann etwas anderes von der Plattform anfordern oder etwas anderes von derselben Antwort speichern. Dann liegt eine glaubwürdige Antwort auf eine Frage vor, die nicht mehr in dieser Form gestellt wird. Die Zeit behebt das nicht: Der vollständige Dokumenttext wird wochenlang gespeichert und überdauert somit mehrere Ausgaben.
Jedes zwischengespeicherte Element speichert daher, durch welche Version von BesluitBron es erstellt wurde. Ein Element, das eine andere Version angibt, wird gelöscht, sobald dies erforderlich ist, und die Plattform wird erneut abgefragt. Es wird nichts im Voraus bereinigt. Nur das, was tatsächlich abgefragt wird, wird geprüft. Ein Neustart kostet daher niemals einen gerade erst aufgebauten Puffer.
Anfragedaten der Plattformen
Die Plattformen unterscheiden sich stark hinsichtlich ihrer Belastbarkeit. Dies wurde gemessen und nicht angenommen. Ein nicht festgestellter Grenzwert ist kein nicht vorhandener Grenzwert. Wenn der Quellenbetreiber keinen Grenzwert veröffentlicht, wird dies als Feststellung bei diesem Quellenbetreiber vermerkt.
| Plattform | Beobachteter Grenzwert |
|---|---|
| Open Raadsinformatie | Es wurde keine Begrenzung festgestellt |
| OpenBesluitvorming | 60 gewichtete Einheiten pro Minute, von der Plattform selbst erzwungen |
| Tweede Kamer | Es wurde kein Grenzwert veröffentlicht und es wurde kein Grenzwert festgestellt |
| OpenTK | keine feste Obergrenze; der Administrator warnt selbst vor teuren Suchanfragen |
| Officiële Bekendmakingen | Beschränkung beim Suchdienst |
| Rechtspraak | Bei beiden Diensten wurde keine Begrenzung festgestellt |
| Open Archivaris | 120 Anrufe pro Minute |
BesluitBron hält sich auf seiner Seite an diese Grenzwerte. Ist der Speicherplatz auf einer Plattform erschöpft, wartet ein Aufruf, bis wieder Speicherplatz verfügbar ist.
Warten auf eine Plattform mit einem Limit
Wenn Platz vorhanden ist, wird jeder Aufruf sofort weitergeleitet. Wenn Aufrufe aus mehreren Sitzungen anstehen, entscheidet der Verbrauch darüber, wer zuerst bedient wird. BesluitBron erfasst pro Sitzung, wie viel Platz bereits verbraucht wurde. Eine Sitzung, die wenig angefordert hat, erhält einen größeren Anteil des Platzes. Eine Sitzung, die viel beansprucht, erhält einen immer kleineren Anteil, je länger sie andauert. Bei OpenBesluitvorming erhält eine Sitzung, die 60 Einheiten verbraucht hat, die Hälfte dessen, was eine neue Sitzung erhält. Nach 120 Einheiten ist dies ein Drittel. Zwei Sitzungen, die gleich viel beanspruchen, erhalten gleich viel. Innerhalb einer Sitzung bleibt die Reihenfolge der Aufrufe gleich. Gibt es nur eine Sitzung, erhält diese den gesamten Speicherplatz.
Eine wartende Sitzung erhält immer Platz, unabhängig davon, wie viel sie bereits beansprucht hat. Sie erhält mindestens einen Aufruf in der Zeit, die das Limit benötigt, um sich vollständig aufzufüllen. Bei OpenBesluitvorming ist das eine Suchanfrage pro Minute. Warten mehr Sitzungen, als in dieser Zeit Aufrufe untergebracht werden können, wird die Sitzung bevorzugt, die am längsten wartet. Ein Aufruf, der mehr kostet als das gesamte Limit, wird ebenfalls ausgeführt. Er verbraucht dann das gesamte Limit.
BesluitBron vergisst den Verbrauch einer Sitzung 30 Minuten nach ihrem letzten Aufruf.
Dies gilt für die Plattformen, für die BesluitBron selbst ein Limit verwaltet: Officiële Bekendmakingen, Open Archivaris, OpenBesluitvorming und Rechtspraak. Die Suchseite und die eigene Wartung von BesluitBron, wie beispielsweise das Abrufen von Laadstatus, zählen zusammen als eine Sitzung. Für diese Seiten wird der Verbrauch nicht mitgerechnet, da sie für viele Besucher gleichzeitig bestimmt sind.
Dies gilt ab Version 1.4.6. Bis einschließlich Version 1.4.5 wurde ein wartender Aufruf nicht in eine Warteschlange eingeordnet. Eine Sitzung konnte dann hinter allen Aufrufen einer stark ausgelasteten Sitzung landen. In einem simulierten Test mit der Begrenzung von OpenBesluitvorming wartete eine zweite Sitzung bis zu 106 Sekunden auf eine einzige Suchanfrage. Ab Version 1.4.6 betrug diese Wartezeit im selben Test weniger als drei Sekunden. Außerdem ließ BesluitBron bis einschließlich Version 1.4.5 bei hoher Auslastung manchmal einen Aufruf durch, ohne ihn zu zählen. So konnte es mehr Aufrufe senden, als das Limit zuließ.
Wie oft ein Client „BesluitBron“ aufrufen darf
Die oben genannten Beschränkungen dienen dem Schutz der Quellplattformen. Eine zweite Beschränkung schützt BesluitBron selbst. Die MCP-Adressen verfügen über keine Authentifizierung, daher gilt eine Geschwindigkeitsbegrenzung für die Anfragen, die ein Client an BesluitBron sendet. Ohne diese Begrenzung würde ein einzelner Client mit einer Flut von Anfragen den gesamten Dienst lahmlegen, auch jene Teile, mit denen dieser Client nichts zu tun hat.
Es gibt drei Grenzen, und eine Anfrage durchläuft alle drei:
- eine Begrenzung für den gesamten Prozess, denn eine Flutwelle betrifft den gesamten Dienst und nicht nur eine einzelne Adresse;
- eine Begrenzung pro Anschluss, damit die Belastung an einem Anschluss den anderen nicht beeinträchtigt;
- ein Limit pro Sitzung, und vor jeder Sitzung wird pro Client-Adresse ein Limit festgelegt, damit nicht ein einzelner Client den gesamten Speicherplatz beansprucht.
Ein Client, der einen Grenzwert überschreitet, erhält den HTTP-Status 429 mit einem „Retry-After“. Dies ist die Anzahl der Sekunden, die der Client warten muss, bevor er einen neuen Versuch unternimmt. Die Grenzwerte sind großzügig bemessen und haben bei normaler Nutzung keine Auswirkungen. Ein Administrator kann sie unter BesluitBron:McpRateLimit für eine Installation mit vielen gleichzeitigen Clients erhöhen. Siehe Uitrol en Beheer.
Was einem Leser dabei auffällt
Eine erste Anfrage zu einem Thema dauert länger als eine Folgeanfrage zum selben Thema. Eine Anfrage, für die der vollständige Dokumenttext benötigt wird, dauert länger als eine Anfrage, bei der die Titel ausreichen. Eine Abfrage aller 331 Quellen gleichzeitig dauert länger als eine Abfrage zu einer einzigen Gemeinde. Unmittelbar nach einem Upgrade von BesluitBron dauert eine erste Abfrage erneut länger, da der Puffer der vorherigen Version dann nicht mehr verwendet wird.
Ist dieser Unterschied groß genug, um den Gesprächsverlauf zu beeinflussen, wird dies in den Tools vermerkt. Der Assistent kann dann den kostengünstigeren Weg wählen, sofern dieser ebenfalls zur Antwort führt.