La dernière mouture du Technical Guidance for View Services (version 3.1 donc) est parue au début du mois, alors même que la mise en œuvre en devenait règlementaire pour les Annexes I et II. Pas de grands bouleversements dans cette version donc, mais un éclaircissement sur la notion de Qualité de Service (QoS), qui était alors reléguée au rang d’annexe et dispose désormais d’un chapitre dédié (le chapitre 6).

Comme souvent la notion d’éclaircissement s’accompagne d’une dose d’obscurcissement, voici un petit résumé de ce que j’ai pu en comprendre…

  1. Comment tester ?
    Sans doute pour répondre aux divers besoins exprimés, le document prévoit 2 scénarii de test : soit on teste le service depuis son point d’accès sur internet, soit on le teste depuis l’intérieur de l’infrastructure informatique. Dans ce dernier cas, il faut retrancher le temps de transport réseau pour mesurer la performance. Il s’agit en fait d’établir la différence de temps de transfert entre ce mode et le mode précédent, et de l’appliquer aux résultat obtenus ainsi. C’est une sorte d’extrapolation des résultats qu’on aurait obtenus en testant depuis l’extérieur faite à partir de résultats obtenus depuis l’intérieur de l’infrastructure. Bon, pour la suite, on partira du principe qu’on suit le scénario 1…
  2. Mesure de la performance.
    Il faut pouvoir récupérer une image de 470 Ko (800×600 pixels en 8 bits) en moins de 5 secondes, en situation normale. Mais il ne suffit pas que ça marche une fois. Le protocole de mesure indique qu’il faut effectuer plusieurs tests par heure (au moins 10), en n’interrogeant qu’une couche à la fois, mais en faisant varier la bbox pour éviter les effets d’une mise en cache éventuelle. Au final, 90% des mesures doivent être inférieures à ces 5 secondes (c’est la notion de situation normale).  Le chronométrage doit correspondre au premier bit reçu par le client, et non à la réception de l’ensemble de la réponse.
  3. Mesure de charge
    Le nombre minimum de requêtes servies doit être de 20 par seconde.  Cette mesure doit être effectuée pendant 1 minute, en envoyant 20 requêtes simultanées par seconde (ce qui associé à l’exigence précédente suppose une bande passante d’au moins 75 Mbps). Pour éviter les biais, il est préférable de réaliser ce test en ayant désactivé l’accès public au service. Concrètement, un test avant la mise en production semble idéal, puis régulièrement (mensuellement selon la recommandation). Dans les 20 requêtes minimum envoyées par seconde, il faut prévoir 10 % de GetCapabilities et 90 % de GetMap (faits selon les exigences de performance vues précédemment).
  4. Disponibilité.
    Le service doit être disponible (mais sans forcément atteindre les exigences précédente) 99 % du temps, soit 3,63 jours d’indisponibilité par an au maximum.  Il faut faire au minimum 10 requêtes par heure, qui peuvent être les mêmes que celles utilisées pour mesurer la performance. Néanmoins, les périodes de maintenance ne rentrent pas en compte dans cette mesure, pour peu qu’elles aient été signalées aux utilisateurs (via les portails ou une notification par mail) une semaine à l’avance.

En résumé, si l’on met de côté la mesure de charge qui est particulière, il faut mettre en place un système qui envoie des GetMap sur un layer, en 800×600 avec bbox variable (mais valide, c’est-à-dire incluse dans la bbox du layer tel qu’exposée par le GetCapabilities) plus de 10 fois par heure. Au moins 99 % de ces requêtes doivent aboutir à un résultat (HTTP 200 et image non vide), et le premier bit de ce résultat doit être obtenu en moins de 5s dans au moins 90% des cas. Vous remarquerez néanmoins sans doute un paradoxe : les ViewServices peuvent utiliser du WMS ou du WMTS, mais les indicateurs de QoS ne prévoient pas de mesure particulière sur du GetTile, équivalent en WMTS du GetMap. Si votre service de visualisation WMS ne répond pas aux exigences de qualité de service, vous n’avez donc plus qu’à le basculer en WMTS !

Qualité de service des services de visualisation INSPIRE
Étiqueté avec :    

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.