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é. Ainsi, une conversation animée ne perturbe pas le service d'autrui.
À 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.