Le titre de ce billet correspond à une question reçue (très) régulièrement par notre support. La réponse n'est pas immédiate, comme évoqué précédemment pour le temps nécessaire à l'interrogation d'une base de données, il n'y a pas un temps "normal".
Si l'utilisation des webservices apporte une très grande simplicité pour échanger des données entre différentes plateformes et solutions hétérogènes, leur fonctionnement repose sur nombreux processus qui ont tous une incidence sur le temps de réponse.
Voici les différentes étapes incontournables pour l'appel d'une API REST :
- exécution du code qui prépare la requête HTTPS (paramétrage des entêtes, token, cookie, chargement du contenu "body" pouvant venir d'une base de données...),
- appel de la fonction HTTPEnvoie (idem RestEnvoie, HTTPRequête, HTTPEnvoieFourmulaire...) qui va faire l'envoi effectif de la requête HTTPS.
- acheminement de la requête HTTPS par la connexion réseau qui relie le poste qui exécute l'application avec le serveur web qui héberge le webservice. Pour ce transfert sont déterminants :
- la latence de la connexion (durée incompressible),
- la taille du contenu de la requête lorsqu'elle a des données dans son contenu "body", à mettre en relation avec le débit de la connexion,
- Le serveur web qui héberge le webservice reçoit la requête HTTPS, sachant qu'avant tous les dispositifs de sécurité traversés (routeurs, proxy, antivirus...) ont pu avoir une action le délai d'acheminement des trames.
Le serveur web va :
- mettre à jour ses logs d'activité,
- valider une éventuelle authentification configurée à son niveau,
- rechercher le processus associé au type de la requête reçue,
- appeler le processus WD270AWP.EXE du serveur d'application qui héberge le webservice.
- le processus WD270AWP.EXE reçoit la demande, contrôle si l'exécution est autorisée (limite du nombre de connexions du serveur et/ou de ce webservice...), et lance une instance du processus WD270SESSION.EXE pour exécuter le code du webservice.
- WD270SESSION.EXE exécute :
- le code du projet,
- le code de la procédure prologue pour valider une éventuelle authentification programmée dans le webservice,
- et enfin le code de la procédure qui se terminera par un RENVOYER de la réponse formatée. Si le traitement retourne des données, il y aura connexion et interrogation à la base de données. Un temps de latence peut à nouveau s'appliquer si le moteur contacté est localisé sur un autre serveur.
- la réponse renvoyée doit effectuer tout le cheminement réseau inverse, en reprenant en compte la latence, le délai nécessaire au transfert de son volume en fonction du débit.
- l'application reprend la main après le RestEnvoie afin de traiter une éventuelle erreur, ou le contenu...
Le même principe s'applique pour tous les échanges qui reposent sur HTTP/HTTPS :
- la consommation d'un webservice SOAP,
- l'appel d'une page en mode AWP qui retourne un contenu avec la fonction ChaineAffiche,
- l'appel d'un script PHP. Dans ce cas c'est le moteur PHP qui est exécuté à la place du serveur d'application de WEBDEV...
Donc le temps global pour un appel, est dépendant de l'ensemble des protagonistes décrits ci-dessus...
Lorsqu'un temps de réponse ne semble pas conforme, il faut donc suivre l'ensemble du cheminement afin de situer une éventuel goulet d'étranglement.
A voir en premier lieu :
- la latence de la connexion vers le serveur qui héberge le webservice. Elle est indépendante du volume de la requête et de la réponse. Même la requête la plus petite va imposer au minimum le temps de latence à l'aller et au retour.
- côté client, l'analyseur de performances et ses fonctions AnalyseurDébut et AnalyseurFin. Il permet de voir immédiatement si le temps est consacré réellement à l'appel du webservice, ou à préparation de la requête, ou au traitement de la réponse. Par exemple si la réponse retourne un lot de données formatées en JSON qui doivent être insérées dans une base de données, c'est peut être ce transfert qui prend davantage de temps et doit être optimisé, plutôt que l'appel du webservice),
- côté webservice :
- le chargement d'une nouvelle instance d'un processus est coûteuse pour les systèmes d'exploitation. Les sessions prélancées permettent d'avoir un lot de processus prêts à l'emploi pour exécuter les requêtes à venir.
- la connexion aux bases de données est également souvent aussi coûteuse en temps que l'interrogation qui suit. Il faut préférer une connexion au niveau du projet, combinée avec l'utilisation des sessions prélancées : la procédure sera ainsi appelée avec un accès aux données le plus rapide possible.
- à partir de la version 28 la fonction DBGActiveLog permet d'avoir un log d'exécution des traitements du webservice. Le log peut montrer rapidement quel traitement peut être optimisé.
- et enfin s'il reste à ce stade des interrogations, pour aller plus loin il faudra se pencher sur :
- les logs du serveur web qui héberge le webservice à recouper avec les données des logs du serveur d'application de WEBDEV,
- les éventuelles remontées de l'observateur d'événements du système serveur,
- les logs des éventuels dispositifs de sécurité, proxy & co,
- une analyse des échanges réseau :
J'en profite pour ajouter une mention sur les "timeout" qui peuvent s'appliquer lors de l'appel d'un webservice. Tous les processus sollicités ont un timeout. Lorsqu'un webservice est appelé pour une opération particulièrement longue, si un timeout survient avant la réponse il peut être au niveau :
- de l'application qui appelle le webservice qui peut interrompre l'appel avant la réception de la réponse.
Ce timeout est fixé par la propriété DuréeNonRéponse du type HttpRequete ou RestRequête.
- du serveur web qui a transmis une demande au serveur d'application. Il ne reste pas indéfiniment en attente de la réponse. Il retourne de lui-même une réponse "HTTP Timeout" si le serveur d'application ne lui donne pas la réponse dans un laps de temps configuré dans ses réglages.
- du serveur d'application de WEBDEV qui retourne une réponse ERR_TIMEOUT si le temps d'exécution d'une procédure, dépasse le temps configuré dans les réglages de l'administrateur de WEBDEV sur le serveur...
|