Une requête d’un utilisateur donne souvent lieu à plusieurs appels, et chaque appel est acheminé vers un service tiers. La mise en mémoire tampon détermine donc deux éléments : la vitesse à laquelle s’effectue une conversation, et la charge que BesluitBron impose aux plateformes sources.
Mise en mémoire tampon par plateforme
La mémoire tampon est séparée pour chaque plateforme. Une plateforme qui répond lentement ou qui est temporairement inaccessible ne ralentit pas les six autres. Le fait de vider la mémoire tampon d'une plateforme n'affecte pas les autres.
Les données mises en mémoire tampon dépendent de la nature des données :
- Les listes qui changent rarement, telles que les organismes sources, les commissions, les groupes parlementaires et les listes de valeurs de la plateforme « Rechtspraak », sont conservées pendant longtemps. Ces listes changent tous les quelques mois ;
- Les résultats de recherche ne sont conservés que brièvement. Ainsi, un assistant qui répète la même question au cours d'une même conversation ne sollicite pas deux fois la plateforme ;
- Le texte complet du document est conservé aussi longtemps que cela se justifie, car sa récupération est l'opération la plus coûteuse effectuée par ce produit.
Non valable après une mise à jour
Une réponse mise en cache est la réponse telle qu'une plateforme, comme une version donnée de BesluitBron, l'a lue et enregistrée. Une nouvelle version peut interroger la plateforme différemment ou enregistrer une version légèrement différente de la même réponse. Il en résulte alors une réponse fiable à une question qui n’est plus posée sous cette forme. Le temps n’y change rien : le texte intégral du document est conservé pendant plusieurs semaines et survit ainsi à plusieurs éditions.
Chaque élément mis en mémoire tampon enregistre donc la version de BesluitBron à partir de laquelle il a été généré. Un élément qui fait référence à une autre version est supprimé dès qu’une requête l’exige, et la plateforme est à nouveau interrogée. Aucun nettoyage préalable n’est effectué. Seules les données effectivement demandées sont évaluées. Un redémarrage n’entraîne donc jamais la perte d’un tampon qui vient d’être constitué.
Limites de requêtes des plateformes
Les plateformes présentent de grandes différences quant à leur capacité de résistance. Ces données ont été mesurées et ne reposent pas sur des hypothèses. Une limite non observée n'est pas une limite inexistante. Lorsque le détenteur de la source ne publie pas de limite, cela est signalé comme constatation auprès de ce détenteur.
| Plateforme | Limite observée |
|---|---|
| Open Raadsinformatie | aucune limite n'a été constatée |
| OpenBesluitvorming | 60 unités pondérées par minute, imposées par la plateforme elle-même |
| Tweede Kamer | aucune limite publiée et aucune limite observée |
| OpenTK | pas de limite stricte ; c'est l'administrateur qui avertit lui-même en cas de recherches coûteuses |
| Officiële Bekendmakingen | limite imposée par le moteur de recherche |
| Rechtspraak | aucune limite n'a été constatée sur ces deux services |
| Open Archivaris | 120 appels par minute |
BesluitBron respecte ces limites de son côté. Si l'espace disponible sur une plateforme est épuisé, une requête est mise en attente jusqu'à ce qu'il y ait à nouveau de l'espace disponible.
En attente d'une plateforme avec une limite
S'il reste de l'espace, chaque requête est traitée immédiatement. Si des requêtes provenant de plusieurs sessions sont en attente, c'est la consommation qui détermine l'ordre de priorité. BesluitBron garde la trace, pour chaque session, de l'espace déjà utilisé. Une session qui a peu sollicité le système se voit attribuer une plus grande partie de l'espace. Une session très gourmande se voit attribuer une part de plus en plus réduite à mesure qu’elle se prolonge. À OpenBesluitvorming, une session ayant utilisé 60 unités reçoit la moitié de ce qu’obtient une nouvelle session. Au-delà de 120 unités, ce pourcentage passe à un tiers. Deux sessions qui sollicitent autant de ressources se voient attribuer la même quantité. Au sein d’une même session, l’ordre des appels reste inchangé. S’il n’y a qu’une seule session, celle-ci se voit attribuer la totalité de l’espace.
Une session en attente se voit toujours attribuer de l'espace, quel que soit le volume qu'elle a déjà utilisé. Elle reçoit au moins un appel pendant le temps nécessaire à la limite pour se remplir entièrement. Dans le cas de OpenBesluitvorming, cela correspond à une requête par minute. Si le nombre de sessions en attente dépasse le nombre d'appels pouvant être traités pendant ce laps de temps, la session qui attend depuis le plus longtemps est traitée en priorité. Un appel dont le coût dépasse la limite totale est également traité. Il utilise alors la totalité de la limite.
BesluitBron oublie la consommation d'une session trente minutes après son dernier appel.
Cela s'applique aux plateformes pour lesquelles BesluitBron gère lui-même une limite : Officiële Bekendmakingen, Open Archivaris, OpenBesluitvorming et Rechtspraak. La page de recherche et la gestion interne de BesluitBron, comme la récupération de l'Laadstatus, comptent ensemble comme une seule session. Pour celles-ci, la consommation n'est pas prise en compte, car elles accueillent simultanément un grand nombre de visiteurs.
Ceci s'applique à partir de la version 1.4.6. Jusqu'à la version 1.4.5 incluse, un appel en attente n'était pas placé dans une file d'attente. Une session pouvait alors se retrouver derrière tous les appels d'une session très chargée. Dans un test simulé avec la limite de OpenBesluitvorming, une deuxième session attendait jusqu’à 106 secondes pour une seule requête. À partir de la version 1.4.6, ce temps était inférieur à trois secondes dans le même test. La plus, jusqu’à la version 1.4.5 incluse, BesluitBron laissait parfois passer une requête en cas de forte affluence sans la comptabiliser. Il pouvait ainsi envoyer plus de requêtes que ne le permettait la limite.
À quelle fréquence un client peut-il appeler BesluitBron ?
Les limites mentionnées ci-dessus protègent les plateformes sources. Une deuxième limite protège BesluitBron lui-même. Les adresses MCP ne font l'objet d'aucune authentification ; une limite de débit est donc imposée aux requêtes qu'un client envoie à BesluitBron. Sans cette limite, un seul client, en inondant le système de requêtes, pourrait paralyser l'ensemble du service, y compris les composants qui ne le concernent pas.
Il y a trois limites, et une requête les franchit toutes les trois :
- une limite pour l'ensemble du processus, car un afflux massif affecte l'ensemble du service et non une seule adresse ;
- une limite par connecteur, afin que la charge sur un connecteur n'affecte pas l'autre ;
- une limite par session, et avant chaque session, une limite par adresse client, afin qu'un seul client ne monopolise pas tout l'espace.
Un client qui dépasse une limite reçoit un code HTTP 429 avec une valeur « Retry-After ». Il s'agit du nombre de secondes à attendre avant que le client ne réessaie. Les limites sont largement fixées et n'affectent pas une utilisation normale. Un administrateur peut les augmenter à l'adresse BesluitBron:McpRateLimit pour une installation comportant de nombreux clients simultanés. Voir Uitrol en Beheer.
Ce qu’un lecteur remarque à ce sujet
Une première requête sur un sujet prend plus de temps qu'une requête suivante portant sur le même sujet. Une requête nécessitant le texte intégral d'un document prend plus de temps qu'une requête pour laquelle les titres suffisent. Une requête portant sur l'ensemble des 331 sources à la fois prend plus de temps qu'une requête concernant une seule commune. Immédiatement après une mise à jour de BesluitBron, une première requête prend à nouveau plus de temps, car la mémoire tampon de la version précédente n'est alors plus utilisée.
Si cette différence est suffisamment importante pour orienter la conversation, elle est indiquée dans les outils. L'assistant peut alors opter pour la solution la moins coûteuse si celle-ci fournit également la réponse.