Le temps de réponse

La ?time line? Le temps de réponse dépend de plusieurs temps additionnés, comme le montre ce graphique simplifié Nom Description Type de temps Dépend du volume (compression utile) Action UBFast Name resolution pour Domain Name resolution (DNS) Retrouve l?adresse IP du serveur à partir du nom de la page A chaque requête ? Non Pas d?action Connection Temps de connection au réseau 1 connexion par page Non Pas d?action Query upload Chargement de la requête (Ne pas confondre requêtes et pages) A chaque nouvelle requête sauf caching Oui. Négligeable Oui Minimise le nombre de requêtes Cache navigateur Cache serveur RTT (pour Round Trip Time) A chaque requête Oui A priori NON. Exception : utilisation d?un CDN Exception : déploiement de plusieurs UBFast Think time Temps nécessaire au serveur pour construire (calculer) la page Serveur Non Oui UBFast décharge le serveur de certains travaux Reply in Oui Compression Cache navigateur Reply out Oui Compression Cache serveur Accélération des applications Web L'accélération des applications Web n'est pas une simple compression. En fait, de nombreux facteurs ralentissent la livraison des données. La compression seule ne résout pas toujours le problème. C'est le cas des temps de traitement du serveur et de la latence du réseau, c'est-à-dire le temps de propagation qu'un paquet prend pour se déplacer d'un point à un autre à distance du serveur et du navigateur (ou tout autre agent HTTP). En outre, il existe de nombreux types de données, telles que les images et les vidéos déjà compressées, qui ne peuvent donc plus être réduites. En effet, en moyenne, les composants graphiques incompressibles représentent la plus grande partie des transferts de données en volume et en nombre de requêtes (98% des requêtes HTTP et 70% du volume). Dans tous les cas, la réduction du poids des données transmises est un facteur d'amélioration du temps de réponse. Les temps de propagation Le temps de propagation est le temps nécessaire à un paquet pour traverser le réseau d'un point à un autre. Il est donc comparable à une onde de choc dans un milieu ou une onde électrique dans un câble. Ce temps peut être mesuré en utilisant la commande ping. Pour être plus précis, ping mesure le temps nécessaire à un paquet pour atteindre sa destination et son retour, également connu sous le nom de Round Trip Time (RTT). Dans un réseau local (LAN), cette durée est négligeable - généralement quelques millisecondes seulement. Sur Internet, cette durée peut atteindre des centaines de millisecondes en raison des distances physiques impliquées et du grand nombre de routeurs et d'autres équipements. Le résultat d'un ping peut donc être utilisé pour mesurer la distance entre deux points sur le réseau. Ainsi, il est possible de dire que nous sommes à 70 ms de www.someothersite.int. Par exemple, la France est à 50 ms du reste de l'Europe occidentale, à 120 ms de la côte est de l'Amérique du Nord et à environ 220 ms de la côte ouest. Si la connexion est acheminée via un satellite, les temps de propagation dépassent 600 ms. Un aller-retour par satellite nécessite que les données parcourent quatre fois la distance entre la Terre et l'orbite géostationnaire, soit quatre fois 37 000 km ou environ 150 000 km, ce qui prend 500 ms. Trois éléments doivent être distingués dans le temps de réponse du site Web. * le temps passé par les serveurs pour générer les données, ce que l'on appelle aussi le temps de réflexion du serveur, * le temps nécessaire pour transmettre les données sur le réseau * et enfin le temps de rendu passé par le navigateur. Le manque de bande passante est l'un des premiers sujets abordés. Elle est corrigée en appliquant diverses formes de compression et une série d'optimisations spécifiques pour chaque type de données. Cela réduit leur volume au-delà de la compression. L'un d'entre eux est le traitement d'image qui permet de diviser leur poids par deux sans dégradation perceptible par les utilisateurs. Cependant, en Europe, la bande passante est disponible partout. De plus, sauf dans les cas extrêmes, la bande passante joue un rôle minime dans le temps de réponse de l'application. Le temps de propagation dans le réseau et l'architecture des pages de l'application qui commande la programmation des requêtes soumises par le navigateur représentent en réalité plus des deux tiers du temps d'affichage. Ce délai, également appelé Round Trip Time, est responsable d'une grande partie du temps de transfert des données. Il prend des valeurs allant d'environ 30 millisecondes à parfois plus de 250 millisecondes via des réseaux mobiles. Cette durée est multipliée par le nombre d'éléments composant la page HTML. C'est également la cause d'une restriction de la bande passante par session de session TCP due aux mécanismes d'acquittement des paquets (dénommé "problème de produit de délai de bande passante"). Pour commencer, vous devez faire un diagnostic. La première étape consiste à faire une évaluation d'un point de vue externe du temps de réponse de l'application. Lorsque la détérioration du temps de réponse est prouvée, une série de mesures peut être utilisée pour évaluer chaque cause du ralentissement. L'intégration de l'équipement de mesure est facilitée par l'agilité inhérente du nuage. Cela est organisé sur le chemin de données en aval de l'infrastructure de l'application. Cela donne une vision des deux côtés de la livraison du contenu de l'application: sa production et son transfert via le réseau. Le même équipement peut ensuite mettre en ?uvre toutes les techniques d'optimisation appliquées au contenu et à la transmission. Comment adresser les temps de propagation Il est facile de voir que la compression a un effet décroissant lorsque le temps de propagation est grand. Un aspect clé de la solution dans ce cas est d'éviter de transférer toutes les données jusqu'au bout. UBFAST rend cela possible. Contrôle du cache distant Le contrôle de cache distant implique l'utilisation optimisée de caches dans la chaîne de proxy et, en particulier, le propre cache du navigateur. Le service HTTP de UBFAST peut affiner les directives de mise en cache, contrôlant ainsi la gestion de la mise en cache tout au long de la chaîne de proxy. Le système DynaFlex de UBFast permet une configuration très précise de la mise en cache des données, même URL par URL. Cela signifie, par exemple, qu'un logo peut avoir une durée de vie de trois mois, tandis que les icônes seront mises en cache indéfiniment et d'autres images seulement pendant quelques minutes. Grâce à ce système, les clients voient une diminution spectaculaire du nombre de demandes soumises au serveur HTTP réel. Le taux de diminution est à peu près proportionnel au nombre de composants dans la page HTML. Par exemple, une page contenant 50 composants verra généralement les requêtes divisées par 50. Dans ces conditions, il est facile de voir à quel point le contrôle du cache distant est efficace. Distribution géographique Une autre solution consiste à rapprocher les données du navigateur. Dans ce cas, un réseau de caches régionaux est requis et le navigateur doit être configuré pour soumettre ses requêtes graphiques au cache le plus proche. Ce type de réseau s'appelle un CDN (Content Delivery Network). UBFAST peut être utilisé pour incorporer facilement un site Web dans un CDN sans nécessiter de délégation de nom de domaine. La performance et le cloud De nombreuses entreprises ont prévu de transférer leurs applications Web dans le cloud et une partie importante d'entre elles a déjà ou est en train de le faire. Lorsque les applications sont situées dans les locaux de l'entreprise, nous bénéficions d'un accès local via le réseau local de l'entreprise. Dans le cas du e-commerce on aura avec le cloud un accès distant, ce qui peut entraîner une dégradation des performances de l'application. L'ubiquité est l'une des caractéristiques du cloud. En effet, les plateformes cloud, en particulier Google Cloud Platform et Amazon Web Services, sont partitionnées par région. Ceci, en fait, réduit l'omniprésence des données et, par conséquent, la plupart des utilisateurs situés loin de la région d'implémentation de l'infrastructure souffrent de l'allongement du chemin de données. Le Round Trip Time (RTT) Le RTT est responsable d'une grande partie du temps de transmission des données, il peut être vu comme un temps de propagation. Il prend des valeurs très diverses allant d'environ 30 ms en Europe, de 100 à 250 ms sur un réseau mobile et jusqu'à 950 ms dans le cas d'une transmission par satellite (VSAT). Indépendamment de la bande passante, une réponse à une demande d'aller-retour durera au moins ce RTT. Une page HTML est composée de plusieurs dizaines d'éléments, sa construction nécessite donc autant de requêtes HTTP. La solution réside dans l'utilisation précise et efficace du cache du navigateur. Cela nécessite que vous incluiez des directives de contrôle de cache explicites dans chaque réponse HTTP afin que le navigateur ait autant de composants que possible, évitant ainsi de nombreuses requêtes. Le RTT est également la cause d'une limitation de la bande passante par session de session TCP en raison des mécanismes d'accusé de réception des paquets (appelé "problème de produit de délai de bande passante"). Par exemple, un utilisateur réunionnais téléchargeant un fichier depuis la France dispose d'une bande passante effective limitée à 4,5 Mb / s malgré une connexion ADSL de 20 Mb / s et la réservation d'un lien STM1 complet entre la Réunion et Paris. L'optimisation TCP a ici un rôle à jouer, notamment en adaptant les paramètres d'acquittement et les paramètres «en vol». L'emboutissage des paquets IP au moyen de l'indicateur DiffServ en fonction du type et du rôle des données permet également de tirer parti des équipements réseau traversés: plus de priorité sera donnée à une réponse de requête AJAX ou aux composants nécessaires à la construction de la page Render -blocking ") qu'à une image d'arrière-plan. La choréographie de la demande du navigateur Le mot "choréographie" vient du vocabulaire du service Web. Cela signifie que les requêtes sont planifiées par le navigateur afin d'acquérir tous les composants de la page. Selon l'ordre de la demande, le temps de rendu peut varier. La conception de page HTML moderne nécessite une grande quantité de JavaScripts et de feuilles de style CSS. Certains JavaScripts bloquent le rendu de la page et bloquent le processus de rendu jusqu'à ce qu'il soit entièrement téléchargé et analysé. Dans ce cas, réorganiser la page HTML afin de retarder le chargement et l'analyse asynchrone de JavaScript est obligatoire. Déploiement d'un CDN privé L'implémentation d'un CDN (Content Delivery Network) permet de réconcilier les composants statiques des pages des utilisateurs. Il est également possible de profiter du cloud en répartissant des reverse-proxies (appelés «substituts») dans des zones stratégiques et de modifier dynamiquement les pages en fonction de la géolocalisation des utilisateurs et ainsi forcer le navigateur à acquérir les composants des pages à le "substitut" le plus proche.