Fermer

octobre 30, 2018

Mesurer les performances avec la synchronisation de serveur


À propos de l'auteur

Drew est directeur de edgeofmyseat.com, cofondateur de Notist et développeur principal du système de gestion de contenu de petite taille Perch . Auparavant, il était développeur Web…
Pour en savoir plus sur Drew

L'en-tête Server Timing fournit un moyen discret et pratique de communiquer les synchronisations des performances du serveur principal aux outils de développement du navigateur. L'ajout d'informations temporelles à votre application vous permet de surveiller les performances du serveur principal et du serveur principal au même endroit.

Lorsque nous entreprenons des travaux d’optimisation des performances, l’une des premières choses que nous apprenons est qu’avant de pouvoir améliorer les performances, vous devez d’abord les mesurer. Sans être capable de mesurer la vitesse à laquelle quelque chose fonctionne, nous ne pouvons pas savoir si les changements apportés améliorent les performances, n'ont aucun effet, voire aggravent les choses.

Nous sommes nombreux à savoir comment travailler. un problème de performance à un certain niveau. C’est peut-être quelque chose d'aussi simple que d'essayer de comprendre pourquoi le code JavaScript de votre page ne fonctionne pas assez tôt ou pourquoi les images mettent trop de temps à apparaître sur le réseau wifi des hôtels. La réponse à ce type de questions se trouve souvent à un endroit très familier: les outils de développement de votre navigateur.

Au fil des ans, les outils de développement ont été améliorés pour nous aider à résoudre ce type de problèmes de performances lors de l’utilisation des applications. Les navigateurs ont même maintenant des audits de performance intégrés. Cela peut aider à dépister les problèmes initiaux, mais ces audits peuvent révéler une autre source de lenteur que nous ne pouvons pas corriger dans le navigateur. Les délais de réponse du serveur sont lents.

Time to First Byte

Il existe très peu d'optimisations de navigateur pouvant améliorer une page dont la création est simplement lente sur le serveur. Ce coût est encouru entre le navigateur qui demande le fichier et la réponse. L'étude du graphique en cascade de votre réseau dans les outils de développement indiquera ce délai dans la catégorie «En attente (TTFB)». C’est la durée d'attente du navigateur entre la demande et la réponse.

En termes de performances, il est connu sous le nom de Time to First Byte – le temps qu'il faut avant que le serveur commence à envoyer quelque chose au navigateur. peut commencer à travailler avec. Ce temps d’attente comprend tout ce que le serveur doit faire pour créer la page. Pour un site typique, cela peut impliquer de router la demande vers la partie correcte de l'application, de l'authentifier, de faire plusieurs appels à des systèmes dorsaux tels que des bases de données, etc. Il peut s’avérer nécessaire d’exécuter du contenu via des systèmes de modèles, de faire des appels d’API à des services tiers, voire d’envoyer des courriels ou de redimensionner des images. Tout travail effectué par le serveur pour répondre à une demande est ancré dans cette attente TTFB que l'utilisateur doit utiliser dans son navigateur.

 Le panneau Réseau de Chrome DevTools montre l'inspection d'une requête à une seule page
L'inspection d'une requête de document affiche le le temps passé par le navigateur à attendre la réponse du serveur.

Alors, comment pouvons-nous réduire ce temps et commencer à fournir la page plus rapidement à l'utilisateur? Eh bien, c’est une grande question, et la réponse dépend de votre application. C'est le travail d'optimisation de la performance lui-même. Ce que nous devons faire en premier lieu, c’est de mesurer les performances de manière à pouvoir juger du bénéfice de tout changement.

Le travail de Server Timing n’a pas pour but de vous aider à chronométrer votre activité. votre serveur. Vous devrez effectuer vous-même le chronométrage en utilisant les outils que votre plate-forme backend met à votre disposition. Par contre, le but de Server Timing est de spécifier comment ces mesures peuvent être communiquées au navigateur.

La manière dont cela est effectué est très simple, transparente pour l'utilisateur et a un impact minimal sur le poids de votre page. Les informations sont envoyées sous la forme d'un ensemble simple d'en-têtes de réponse HTTP.

 Server-Timing: db; dur = 123, tmpl; dur = 56 

Cet exemple communique deux points de minutage différents nommés db et tmpl . Ce ne sont pas des spécifications – ce sont des noms que nous avons choisis, dans ce cas, pour représenter des timings de base de données et de modèles, respectivement.

La propriété dur indique le nombre de millisecondes que l'opération a effectuées. a pris pour compléter. Si vous examinez la requête dans la section Réseau des Outils de développement, vous pouvez constater que les timings ont été ajoutés au graphique.

 Le panneau Timings d'une demande de page dans Chrome DevTools affichant une nouvelle section Timing du serveur.
Une nouvelle section intitulée Server Timing (Synchronisation du serveur) apparaît et présente les temporisations définies avec l'en-tête HTTP Server-Timing.

L'en-tête Server-Timing peut contenir plusieurs métriques séparées par des virgules:

 Server-Timing: métrique, metric, metric 

Chaque métrique peut spécifier trois propriétés possibles

  1. Un nom court pour la métique (tel que db dans notre exemple)
  2. A duration en millisecondes (exprimé par dur = 123 )
  3. description (exprimé par desc = "ma description" )

chaque propriété est séparé par un point-virgule comme séparateur. Nous pourrions ajouter des descriptions à notre exemple, comme suit:

 Server-Timing: db; dur = 123; desc = "Base de données", tmpl; dur = 56; desc = "Traitement de modèle" 
 Le panneau Timings d'une page requête dans Chrome DevTools montrant les descriptions utilisées pour les métriques Server Timing.
Les noms sont remplacés par des descriptions lorsqu'ils sont fournis.

La seule propriété requise est name . dur et desc sont facultatifs et peuvent être utilisés facultativement si nécessaire. Par exemple, si vous avez besoin de déboguer un problème de minutage qui se produisait sur un serveur ou un centre de données et non un autre, il peut être utile d'ajouter cette information à la réponse sans un délai associé.

 Server-Timing: datacenter; desc = "Centre de données de la côte est", db; dur = 123; desc = "Base de données", tmpl; dur = 56; desc = "Traitement de modèle" 

Cela s'afficherait avec les minutages.

 Panneau d'une requête de page dans Chrome DevTools affichant un minutage de serveur sans heure définie.
La valeur "Centre de données de la côte Est" est affichée, même si elle n'a pas de minutage.

Vous remarquerez peut-être que le minutage les barres n'apparaissent pas dans un motif en cascade, tout simplement parce que Server Timing n'essaie pas de communiquer la séquence de timings, mais simplement les métriques brutes elles-mêmes.

Implémentation du serveur

The L’implémentation exacte dans votre propre application dépendra de votre situation particulière, mais le prin ciples sont les mêmes. Les étapes seront toujours les suivantes:

  1. Heure des opérations
  2. Rassemblez les résultats de chronométrage
  3. Sortie de l'en-tête HTTP

Sous pseudocode, la génération de réponse pourrait ressembler à ceci:

 startTimer (' db ')
getInfoFromDatabase ()
stopTimer ('db')

startTimer ('geo')
geolocatePostalAddressWithAPI ('10 Downing Street, Londres, Royaume-Uni ')
endTimer ('geo')

outputHeader ('Server-Timing', getTimerOutput ()) 

Les bases de la mise en oeuvre de quelque chose dans ce sens devraient être simples, peu importe la langue. Une implémentation très simple de PHP pourrait utiliser la fonction microtime () pour les opérations de chronométrage et ressembler à quelque chose de ce qui suit:

 class Timers
{
    private $ timers = [];

    Fonction publique startTimer ($ name, $ description = null)
    {
        $ this-> timers [$name] = [
            'start' => microtime(true),
            'desc' => $description,
        ];
    }

    fonction publique endTimer ($ name)
    {
        $ this-> minuteries [$name]['end']  = microtime (vrai);
    }

    fonction publique getTimers ()
    {
        $ metrics = [];

        if (count ($ this-> timers)) {
            foreach ($ this-> minuteries en tant que $ name => $ timer) {
                $ timeTaken = ($ timer ['end'] - $ timer ['start']) * 1000;
                $ output = sprintf ('% s; dur =% f', $ name, $ timeTaken);

                if ($ timer ['desc']! = null) {
                    $ output. = sprintf ('; desc = "% s"', addedlashes ($ timer ['desc']));
                }
                $ metrics [] = $ output;
            }
        }

        return implode ($ metrics, ',');
    }
} 

Un script de test l'utiliserait comme ci-dessous, en utilisant ici la fonction usleep () pour créer artificiellement un retard dans l'exécution du script afin de simuler un processus dont l'exécution prend du temps.

 $ Timers = new Timers ();

$ Timers-> startTimer ('db');
usleep ('200000');
$ Timers-> endTimer ('db');

$ Timers-> startTimer ('tpl', 'Templating');
usleep ('300000');
$ Timers-> endTimer ('tpl');

$ Timers-> startTimer ('geo', 'Géocodage');
usleep ('400000');
$ Timers-> endTimer ('geo');

header ('Server-Timing:'. $ Timers-> getTimers ()); 

L'exécution de ce code a généré un en-tête qui ressemblait à ceci:

 Server-Timing: db; dur = 201.098919, tpl; dur = 301.271915 ; desc = "Modèles", geo; dur = 404.520988; desc = "Géocodage" 
 Le panneau Synchronisations d'une demande de page dans Chrome DevTools affichant les valeurs de test correctement affichées.
Les synchronisations de serveur définies dans l'exemple s'affichent. dans le panneau Timings avec les délais configurés dans notre script de test.

Implémentations existantes

Compte tenu de la commodité de Server Timing, peu d’implémentations ont été trouvées. Le paquet NPM de serveur-timing constitue un moyen pratique d’utiliser les projets Server Timing from Node.

Si vous utilisez un framework PHP basé sur un middleware, tuupola / server-timing-middleware fournit une option pratique aussi. J'utilise cela dans la production de Notist depuis quelques mois et je laisse toujours quelques réglages de base activés si vous souhaitez voir un exemple dans la nature.

Le meilleur que j'ai vu est dans Chrome DevTools, et c'est ce que j'ai utilisé pour les captures d'écran de cet article.

Considérations

Server Timing ajoute un temps système très minime à la réponse HTTP renvoyée sur le réseau. L'en-tête est très minime et peut généralement être envoyé en toute sécurité, sans se soucier de cibler uniquement les utilisateurs internes. Même dans ce cas, il vaut la peine de garder les noms et les descriptions courts pour ne pas ajouter de surcharge inutile.

Le travail supplémentaire que vous effectuez sur le serveur pour chronométrer votre page ou votre application est encore plus préoccupant. L'ajout de minutage et de journalisation supplémentaires peut en soi avoir une incidence sur les performances, il est donc intéressant de mettre en place un moyen d'activer et de désactiver cette fonction lorsque cela est nécessaire.

L'utilisation d'un en-tête Server Timing est un excellent moyen de garantir que toutes les informations de minutage proviennent de l'avant. -end et le back-end de votre application sont accessibles en un seul endroit. Pourvu que votre application ne soit pas trop complexe, elle peut être facile à mettre en œuvre et opérationnelle très rapidement.

Si vous souhaitez en savoir plus sur Server Timing, vous pouvez essayer les solutions suivantes: :

 Éditorial éclatant (ra)




Source link