Radar

Présentation

Radar constitue l’épine dorsale de la méthodologie de collecte de données. Radar utilise un script JavaScript intégré dans une page de contenu ou dans les pages d’un fournisseur d’applications pour collecter des informations sur les performances et la disponibilité d’un centre de données ou d’une plateforme de livraison.

Le client Radar est une application JavaScript qui s’exécute sur les pages web des clients et au sein des applications mobiles. Son objectif principal est de collecter des données de performance réseau utilisées pour prendre des décisions de routage intelligentes via Openmix, et de fournir des plug-ins optionnels pour activer d’autres services NetScaler Intelligent Traffic Management, tels que le temps de chargement des pages (Page Load Time), le temps de ressource des pages (Page Resource Timing) et les métriques de lecture vidéo (Video Playback Metrics).

Le client Radar est complet, léger et discret. Le client attend que la plupart des ressources de la page soient téléchargées avant d’effectuer l’essentiel de son travail, et toutes les communications réseau sont effectuées de manière asynchrone lorsque cela est possible. Ces instructions spécifient quelle plateforme mesurer ensuite pendant la session, choisie parmi les plateformes communautaires et toute plateforme privée spécifique à ce membre de la communauté. Elles indiquent également les types de mesures à effectuer, qui peuvent inclure la disponibilité, le temps d’aller-retour, le débit ou d’autres collectes de métriques.

Pour le rendre aussi petit que possible, le JavaScript est compilé avec des optimisations avancées à l’aide du Google Closure Compiler. Les fonctionnalités optionnelles avancées sont fournies sous forme de plug-ins pour les clients qui choisissent de les utiliser.

Communauté Radar

Grâce à une approche unique basée sur la communauté, Radar apporte une transparence inégalée aux performances et à la disponibilité mondiales des plus grandes infrastructures publiques, du Cloud Computing et du stockage aux réseaux de diffusion de contenu et d’applications. En utilisant Radar, les clients peuvent rapidement trouver les plateformes les plus performantes — et les moins performantes — pour chacun de leurs visiteurs.

Radar est la première coopérative de surveillance cloud d’Internet. Devenir membre de la communauté signifie un accès illimité à notre base de données de rapports historiques, y compris une segmentation détaillée par fournisseur, pays et réseau.

Être membre de la communauté Radar offre également un ensemble riche d’outils pour capturer les niveaux de service fournis par les infrastructures de diffusion de contenu internes et externes. La capacité d’utiliser les visiteurs de votre site web pour mesurer l’expérience qu’ils recevraient de plateformes non utilisées actuellement par une entreprise est unique à Radar. La même méthodologie permet des évaluations objectives des plateformes cloud tout au long de leur cycle de vie, y compris l’évaluation continue des performances par rapport aux SLA.

En ajoutant une simple balise JavaScript à votre page web ou un SDK aux applications mobiles, les clients peuvent transformer chacun de leurs visiteurs en un « agent de test » virtuel. Radar déclenche des mesures basées sur les appareils en téléchargeant des objets de référence et en comparant les infrastructures internes et externes, les centres de données, les réseaux de livraison et les plateformes cloud tels qu’ils sont perçus par les utilisateurs finaux réels des sites ou des applications web.

Avantages clés de la participation

Radar relève de nombreux défis de livraison web grâce à son approche de surveillance et de collecte de données. Les avantages clés de la participation à la communauté Radar sont :

• Environnement de test massif, avec des utilisateurs finaux dans chaque réseau et à chaque emplacement (plus de 42 000 réseaux reconnus à ce jour).
• Obtenez des informations importantes sur les fournisseurs de services avant l’essai pour prendre une décision plus éclairée.
• Transparence sur les performances des fournisseurs actuels et sur leur comportement dans les zones géographiques où vous avez ou non des utilisateurs.
• Concentrez-vous sur les métriques qui font une réelle différence pour les utilisateurs web et mobiles (Performance, Disponibilité et QoS).
• Vue globale (plus de 190 pays) et illimitée des informations jusqu’aux niveaux du pays, du réseau, de la région et de l’état.
• Données réelles et impartiales en utilisant les données Radar des utilisateurs finaux, qui sont des informations « du monde réel » plutôt qu’un test synthétique ou une estimation.
• Tous les utilisateurs ne sont pas identiques : Comprenez les différentes machines, connexions et appareils.
• Visibilité sur les performances des pages réelles.

Benchmarks

ITM Radar fournit 3 benchmarks principaux :

• Benchmarking communautaire
• Benchmarking privé
• Benchmarking du temps de chargement des pages

Benchmarking communautaire des CDN, du Cloud et des centres de données

Les mesures communautaires proviennent d’un modèle de crowdsourcing, offrant au client une vue des performances et de la disponibilité d’un fournisseur à un niveau géographique et logique global. Les mesures communautaires permettent de faire des comparaisons entre la qualité d’expérience d’un fournisseur telle que perçue par l’utilisateur final et de réaliser une analyse « what-if » (scénario) lors de l’évaluation des fournisseurs et des prestataires pour la distribution de contenu et d’applications. En utilisant un modèle de crowdsourcing, les clients d’ITM bénéficient d’un niveau de granularité et d’une qualité de données accrus pour évaluer et surveiller les performances des fournisseurs, même dans des emplacements où un client peut ne pas avoir une forte densité d’utilisateurs, voire aucun utilisateur.

Les mesures elles-mêmes utilisent un ensemble standard d’objets situés chez les différents fournisseurs de Cloud et de CDN que les utilisateurs finaux téléchargent lorsqu’ils exécutent le client JavaScript Radar, ou la logique du SDK mobile, sur le site ou l’application d’un propriétaire de contenu.

Les métriques suivantes sont ensuite renvoyées à ITM et présentées dans le portail ou les interfaces de rapport API :

• Disponibilité — si l’objet se charge ou non.
• Temps de réponse — le temps nécessaire au serveur pour répondre à une requête ultérieure, une fois que tout le « bruit » lié à l’établissement d’une connexion est terminé. Il s’agit d’une approximation relativement proche du temps d’aller-retour TCP (RTT) entre le navigateur et le fournisseur.
• Débit — il s’agit du taux de données de la connexion, en kilobits par seconde, tel que mesuré à partir de la récupération d’un objet de 100 Ko.

Benchmarking privé

Dans le cadre du déploiement de la balise Radar, ITM offre au client la possibilité de créer ses propres tests de « benchmark » qui sont mesurés par les visiteurs du client. Cela peut concerner les centres de données ou leurs propres contrats CDN et Cloud. Comme pour les mesures de benchmark communautaires, les mêmes métriques sont fournies – Disponibilité, Temps de réponse et Débit – permettant au client d’évaluer efficacement une stratégie de livraison de contenu existante.

Ces informations privées sont uniquement disponibles pour le client et ne sont pas partagées. Exemples d’utilisation :

• Leurs propres architectures de centres de données
• L’utilisation de leur propre objet de test ou page
• L’utilisation de leur propre contrat et compte avec un fournisseur ou un ensemble de fournisseurs spécifique

Benchmarking du temps de chargement des pages Radar

Au sein de Radar, ITM offre au client la possibilité de consulter des informations détaillées sur la manière dont les pages sur lesquelles la balise est implémentée sont téléchargées. ITM fournit des informations qui vous permettent de voir les performances réelles que les utilisateurs finaux expérimentent lorsqu’ils interagissent avec vos pages web. Les données sont fournies via l’API Navigation Timing prise en charge par de nombreux navigateurs de version plus récente.

Balise Radar

La balise Radar peut être intégrée à l’aide d’un extrait de code JavaScript. Pour accéder à la page Balise Radar, procédez comme suit :

1. Connectez-vous au portail NetScaler Intelligent Traffic Management.
2. Dans le menu de navigation de gauche, sélectionnez Radar > Balise Javascript.

La page Balise Radar s’ouvre.

Si vous n’avez pas encore configuré la balise Radar, une barre horizontale orange apparaît en haut de l’écran, vous indiquant que les mesures Radar n’ont pas été détectées.

Cette barre orange apparaîtra également si la balise n’a pas été configurée correctement.

Alternativement, si la balise Radar fonctionne comme prévu, une barre horizontale verte apparaît, vous indiquant que les mesures Radar ont été obtenues avec succès.

Sur cette page, vous pouvez sélectionner la version de la balise applicable à votre utilisation et la copier dans le presse-papiers.

Remarque : Il est important de ne pas modifier cet extrait de code JavaScript. Le code contient des informations importantes qui, si elles sont modifiées, peuvent entraîner un comportement inattendu ou peu fiable.

Intégration de la balise Radar

L’intégration de la balise Radar est relativement simple. Il vous suffit d’ajouter l’un des extraits de code JavaScript ci-dessous au balisage de votre site. Placez-le dans le code HTML des pages que vous souhaitez mesurer. Nous vous recommandons de le placer en bas de page, avant la balise de fermeture </body>.

Balise Radar par défaut

Ceci est la version recommandée de la balise Radar. Cette version attend que l’événement de chargement soit terminé avant de télécharger et d’exécuter le client Radar, garantissant ainsi que l’événement de chargement n’est pas interrompu.

<script>
if (typeof window.addEventListener === "function") {
    window.addEventListener("load", function() {
        if (window.cedexis === undefined) {
            var radar = document.createElement("script");
            radar.src = "//radar.cedexis.com/1/54621/radar.js"; // à remplacer par la valeur spécifique de l'utilisateur
            document.body.appendChild(radar);
        }
    });
}
</script>
<!--NeedCopy-->

Cette version de la balise empêche le téléchargement du client Radar de bloquer l’analyse ultérieure de la page, mais l’exécute avant que l’événement de chargement ne soit déclenché. Elle est principalement destinée aux clients utilisant des paramètres de politique de sécurité du contenu (Content Security Policy) qui empêchent l’utilisation de JavaScript en ligne. Elle est également destinée aux clients utilisant le plug-in QoS vidéo, où le client Radar doit se charger le plus tôt possible.

<script src="//radar.cedexis.com/1/54621/radar.js" async></script>
<!--NeedCopy-->

Mesures récentes

Le tableau Mesures récentes vous permet de consulter les dernières mesures effectuées à l’aide de Radar.

Cliquez sur le bouton Mesures récentes. Il vous fournit les informations suivantes :

• Date et heure de la mesure en UTC.
• Pays où la mesure a été effectuée.
• Plateforme utilisée pour la mesure.
• ID de la plateforme.
• Type de mesure effectuée, c’est-à-dire Temps de connexion (en millisecondes), Temps de réponse (en millisecondes) ou Débit (en kilobits par seconde).
• Valeur réelle de la mesure en millisecondes (pour le temps de connexion et le temps de réponse) ou en kilobits par seconde (pour le débit).

La barre de mesures Radar apparaîtra également sur la page Tableau de bord Radar lors de votre première connexion au portail ITM.

Intégration avec les applications mobiles

L’intégration avec les applications mobiles s’effectue via des wrappers autour de vues web cachées qui exécutent le client JavaScript. Cela garantit que les données collectées dans les navigateurs et les applications mobiles sont cohérentes.

Instructions pour l’intégration de Radar avec une application iOS Le dépôt GitHub suivant contient le code du wrapper et les instructions étape par étape pour l’intégration de Radar avec une application iOS :

Radar Runner pour iOS

Instructions pour l’intégration de Radar avec Android Android Radar est une bibliothèque cliente qui facilite l’intégration de Radar dans les applications Android. Elle peut être trouvée ici :

Bibliothèque AndroidRadar

Intégration avec NetScaler

La balise Radar est importante car elle fournit à Openmix des mesures qui lui permettent de prendre de meilleures décisions de routage. Plus il y a de pages web utilisant la balise, meilleures sont les décisions de routage.

Les méthodes suivantes vous permettent de placer la balise JavaScript Radar dans votre page web à l’aide de NetScaler. Vous pouvez utiliser la ligne de commande ou l’utilitaire de configuration NetScaler.

Ces méthodes vous permettent d’injecter la balise Radar dans vos réponses. Pour injecter la balise Radar, vous devez utiliser des réécritures (rewrites). Les réécritures sont divisées en trois étapes : la création d’actions, la configuration de politiques et la liaison de politiques.

Configuration en ligne de commande

Configuration de l’action de réécriture en ligne de commande

Modèle :

add rewrite action <name> <type> <target> [<stringBuilderExpr>] [-pattern <expression> | -search <expression>] [-refineSearch <string>] [-comment <string>]
<!--NeedCopy-->

Exemple :

add rewrite action radar_tag action insert_after HTTP.RES.BODY(HTTP.RES.CONTENT_LENGTH).BEFORE_STR("</body>") '\"<script async src=\\"//radar.cedexis.com/1/<customer_id>/radar.js\\"></script>\"'
<!--NeedCopy-->

Remarque : Insérez votre propre ID client là où il est indiqué <customer_id>.

Configuration de la politique de réécriture en ligne de commande

Modèle :

add rewrite policy <name> <rule> <action> [<undefAction>] [-comment <string>] [-logAction <string>]
<!--NeedCopy-->

Exemple :

add rewrite policy radar_tag_policy HTTP.RES.HEADER("Content-Type").TO_LOWER.CONTAINS("text/html") radar_tag_action
<!--NeedCopy-->

Liaison de la politique de réécriture en ligne de commande

Modèle 1 :

bind vpn vserver <name> [-policy <string> [-priority <positive_integer>] [-secondary] [-groupExtraction] [-gotoPriorityExpression <expression>] [-type <type>]] [-intranetApplication <string>] [-nextHopServer <string>] [-urlName <string>] [-intranetIP <ip_addr> <netmask> ] [-staServer <URL> [-staAddressType ( IPV4 | IPV6 )]] [-appController <URL>] [-sharefile <string>]
<!--NeedCopy-->

Exemple 1 :

bind vpn vserver <name_of_vserver> -policy radar_tag_policy -type RESPONSE -priority 10
<!--NeedCopy-->

Modèle 2 :

bind cs vserver <name> (-lbvserver <string> | -vServer <string> | (-policyName <string> [-targetLBVserver <string>] [-priority <positive_integer>] [-gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )] [-invoke (<labelType> <labelName>) ] ) | (-domainName <string> [-TTL <secs>] [-backupIP <ip_addr|ipv6_addr|*>] [-cookieDomain <string>] [-cookieTimeout <mins>] [-sitedomainTTL <secs>]))
<!--NeedCopy-->

Exemple 2 :

bind cs vserver <name_of_vserver> -policyName radar_tag_policy -type RESPONSE -priority 10
<!--NeedCopy-->

Modèle 3 :

bind lb vserver <name>@ (<serviceName>@ [- weight <positive_integer>]) | <serviceGroupName>@ | (- policyName <string>@ [-priority <positive_integer>] [- gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )] [-invoke (<labelType> <labelName>) ] )
<!--NeedCopy-->

Exemple 3 :

bind lb vserver <name_of_vserver> -policyName radar_tag_policy -type RESPONSE -priority 10
<!--NeedCopy-->

Modèle 4 :

bind rewrite global <policyName> <priority> [<gotoPriorityExpression>] [-type <type>] [-invoke (<labelType> <labelName>) ]
<!--NeedCopy-->

Exemple 4 :

bind rewrite global radar_tag_policy 100 -type RES_DEFAULT
<!--NeedCopy-->

Configuration de l’utilitaire d’interface graphique

Action de réécriture de l’interface graphique

1. Dans le menu de navigation de gauche de la page Configuration de NetScaler, accédez à AppExpert -> Réécriture -> Actions de réécriture.

2. Sélectionnez le bouton Ajouter.

3. Dans la page Configurer l’action de réécriture, saisissez l’expression comme indiqué dans l’exemple.

4. Dans le script Radar, saisissez votre ID client dans l’espace marqué <customer_id>.

5. Sélectionnez OK. Vous avez terminé la création de votre action de réécriture.

Politique de réécriture de l’interface graphique

1. Dans le menu de navigation de gauche de la page Configuration de NetScaler, accédez à AppExpert -> Réécriture -> Politiques de réécriture.

2. Sélectionnez le bouton Ajouter.

3. Sur la page Configurer la politique de réécriture, saisissez l’expression comme indiqué dans l’exemple.

   

4. Cliquez sur Créer.

Vous avez terminé la configuration de la politique de réécriture.

Liaison de la politique de réécriture de l’interface graphique

Une fois que vous avez configuré votre politique, la dernière étape consiste à lier la politique à l’aide du Gestionnaire de politiques.

1. Accédez à la page Politiques de réécriture.

2. Sélectionnez la politique de réécriture que vous avez créée pour la balise Radar.

3. Accédez au Gestionnaire de politiques.

   

4. Dans la page Gestionnaire de politiques, vous pouvez lier la politique en procédant comme suit.

   • Pour le Point de liaison, vous avez la possibilité de sélectionner Remplacer global, Serveur virtuel VPN, Serveur virtuel de commutation de contenu ou Serveur virtuel d’équilibrage de charge.
   • Pour le Protocole, sélectionnez HTTP.
   • Pour le Type de connexion, sélectionnez Réponse.
   • Pour le Serveur virtuel, utilisez le nom de votre propre serveur virtuel.

   

   • Cliquez sur Continuer.
   • Dans la page suivante, sélectionnez la Politique de réécriture que vous avez créée précédemment.
   • Ajoutez les Détails de liaison.
   • Cliquez sur Lier.

   

Avec les méthodes ci-dessus, vous êtes en mesure d’insérer la balise Radar dans vos pages web. Cependant, il convient de noter qu’il s’agit d’une implémentation de base. Un filtrage supplémentaire peut être effectué pour mieux contrôler les pages sur lesquelles la balise est implémentée.

Configuration de la balise Radar

Vous pouvez configurer Radar sur la page Configuration de la balise Radar.

1. Connectez-vous au portail NetScaler Intelligent Traffic Management.
2. Dans le menu de navigation de gauche, sélectionnez Radar > Configuration de la balise.

La page Configuration de la balise Radar s’ouvre. Ici, vous pouvez définir diverses options pour personnaliser les mesures Radar. Le JavaScript Radar dispose de paramètres que vous pouvez personnaliser pour ajuster les éléments de temporisation et de délai ; le nombre de tests effectués par les utilisateurs finaux pour les mesures communautaires et privées ; et les valeurs de délai d’attente pour mesurer la disponibilité, et ainsi de suite.

Le tableau suivant fournit des informations sur les options de configuration et les paramètres par défaut pour chacune d’elles. Lorsque vous apportez des modifications, assurez-vous de cliquer sur Mettre à jour les paramètres Radar en bas de l’écran pour appliquer les modifications.

*Auto signifie que NetScaler Intelligent Traffic Management détermine le nombre de plateformes à mesurer pour une certaine session, en fonction de l’emplacement de l’utilisateur final. Nous essayons de mesurer davantage de plateformes par session pour les petits réseaux, où les données sont rares, plutôt que pour les grands réseaux, où elles sont denses.

**Il s’agit du nombre maximal de mesures tentées par session. Par exemple, Radar peut mesurer 4 plateformes privées par session, toutes étant configurées pour mesurer à la fois le RTT et le débit. Mais si le nombre maximal de mesures de débit privées est défini sur 2, le client cessera d’inclure les mesures de débit après avoir mesuré les 2 premières plateformes privées. Pour les deux dernières plateformes, il ne mesurera que le RTT.

Les options de temporisation vous permettent de définir la durée pendant laquelle Radar doit attendre avant de commencer à prendre des mesures.

Remarque : Le Délai de démarrage est en secondes, tandis que le Délai de répétition est en minutes.

Options de protocole

Normalement, le client Radar ne mesure que les plateformes dont les URL ont des protocoles correspondant à ceux de la page où il est exécuté. Ces options vous permettent de contourner ce comportement pour les plateformes privées. Par exemple, l’activation de « Toujours autoriser les mesures HTTPS privées » permet au client de mesurer https://myprovider.com/r20.gif à partir de http://example.com, tandis que « Toujours autoriser les mesures HTTP privées » permet au client de mesurer http://myprovider.com/r20.gif à partir de https://example.com.

Ces options doivent généralement être évitées, sauf dans des cas d’utilisation extrêmes. La meilleure façon de garantir une densité de mesures privées adéquate est de configurer vos plateformes pour mesurer les plateformes et les protocoles que vous utilisez réellement en production (et pas plus), et de déployer la balise Radar sur autant de pages de production que possible. Nous appelons parfois cela « Placer Radar là où il est nécessaire » (Putting Radar where it’s needed).

Le taux d’échantillonnage vous permet de définir un pourcentage de pages web (consultées par les utilisateurs) à partir desquelles collecter des mesures. Par exemple, si votre site web reçoit 100 000 pages vues par jour et que vous définissez un taux d’échantillonnage de 5 %, Radar ne collectera des mesures qu’à partir de 5 % des 100 000 pages vues.

Mesures privées

Ces paramètres s’appliquent aux mesures de vos plateformes privées. Les plateformes privées sont celles que vous configurez dans la section Plateformes pour mesurer des CDN spécifiques, des fournisseurs de cloud et d’autres parties de votre infrastructure. Consultez la section Plateformes pour plus d’informations.

Cette option vous permet de configurer le comportement de Radar lors de la transmission d’informations à la communauté.

Désactiver les tests Radar

S’il est nécessaire de désactiver rapidement les mesures Radar en cas d’imprévu, vous pouvez le faire depuis le portail pour éviter des modifications de code d’urgence sur votre site.

Sur la page Configuration de la balise Radar, désactivez les mesures privées, les mesures communautaires ou les deux en cliquant sur le bouton bascule Activé pour le passer à Désactivé.

Cliquez sur Enregistrer la configuration Radar pour confirmer les modifications. Les modifications peuvent prendre une minute ou deux pour se propager, après quoi les mesures Radar s’arrêteront.

Méthodologie du client Radar

Une dimension fondamentale du comportement du client est la session. Toutes les données envoyées par le client sont associées à une session. Les sessions sont créées en effectuant un appel aux serveurs NetScaler® ITM, connu sous le nom de requête d’initialisation. Les sessions expirent assez rapidement, ce qui contribue à garantir que seules les données Radar valides sont acceptées. Grâce à cette fonctionnalité, les mesures Radar arrivent toujours par lots associés à leur ID de transaction de session, et nous nous référons souvent à une « session Radar » pour décrire les mesures qui y sont associées.

Session Radar

Une session Radar est la principale unité de travail effectuée par le client. Elle consiste en une requête aux serveurs NetScaler ITM pour obtenir la configuration du client et un ensemble de plateformes à mesurer, suivie de requêtes pour mesurer ces plateformes et rapporter les résultats. Celles-ci se déroulent de manière asynchrone et sérialisée, de sorte qu’une seule requête a lieu à la fois. Une session typique se termine en moins de 10 secondes.

Types de sondes

Chaque rapport envoyé par le client a un type de sonde associé, qui indique au système le type de mesure et la manière de le traiter. Il indique également les types de mesures à effectuer, qui peuvent inclure la disponibilité, le temps d’aller-retour, le débit ou d’autres collectes de métriques.

Il existe une relation importante entre la disponibilité et le sondage des performances (tel que le temps d’aller-retour et le débit). La disponibilité d’une ressource particulière est toujours mesurée en premier dans toute session de mesure donnée. Ce n’est que si la mesure de disponibilité réussit que des mesures de performance supplémentaires de la même ressource peuvent être prises dans la même session.

Si un réseau particulièrement lent subit une panne de disponibilité, cela peut entraîner une amélioration réelle des performances agrégées des rapports qui incluent ce réseau. Il ne s’agit que d’un artefact de rapport, car NetScaler Intelligent Traffic Management utilise toujours les données de performance les plus granulaires et spécifiques au réseau pour les décisions en temps réel.

Disponibilité

La disponibilité, également connue sous le nom de sondes de démarrage à froid, est destinée à permettre aux services de « réchauffer » leurs caches. Bien qu’il y ait une valeur de mesure associée à cette sonde. Nous utilisons la sonde de disponibilité pour déterminer si le fournisseur est disponible.

Si une plateforme n’est pas configurée pour effectuer une sonde de démarrage à froid, nous utilisons les résultats de la sonde RTT à la place d’un rapport de démarrage à froid pour fournir des métriques de disponibilité.

De même, pour les objets dynamiques qui mesurent les services d’accélération de site, le client télécharge le petit objet de test une seule fois et rapporte la valeur de mesure pour le démarrage à froid et le temps de réponse.

RTT

Débit

Objets de test

Les objets de test sont des fichiers hébergés sur des plateformes et téléchargés par le client pour générer des mesures. Cette section décrit les différents types d’objets de test pris en charge par le client. Tous les types d’objets ne s’appliquent pas à toutes les plateformes.

En-tête requis :

L’en-tête de réponse Timing-Allow-Origin est requis pour permettre l’accès JavaScript aux données de temporisation de bas niveau fournies par l’API Resource Timing. Le paramètre recommandé est Timing-Allow-Origin: *, ce qui indique que l’autorisation d’accéder aux données de temporisation de la ressource doit être accordée au JavaScript s’exécutant sur n’importe quel domaine.

Standard

Les objets de test standard sont des médias que le client télécharge en définissant l’attribut src sur un objet Image. Une fois téléchargé, le client utilise l’API Resource Timing pour collecter des données de performance. Ces objets de test doivent être servis avec l’en-tête de réponse Timing-Allow-Origin. Consultez la section En-tête Timing-Allow-Origin pour plus d’informations.

Standard petit

L’objet de test standard petit est un fichier image d’un seul pixel, utilisé lorsque le client doit effectuer une requête réseau légère.

L’objet de test standard petit est utilisé dans les cas d’utilisation suivants :

• Sondes de démarrage à froid non dynamiques
• Sondes de temps d’aller-retour non dynamiques

Standard grand

L’objet de test standard grand est un fichier image de 100 Ko utilisé pour mesurer le débit d’une plateforme.

Nommage des objets volumineux : Pour calculer le débit, le client doit connaître la taille de l’objet de test. Le client détermine le nom du fichier en recherchant « Ko » quelque part dans le nom du fichier ; r20-100Ko.png, par exemple. Les clients peuvent mesurer des fichiers image de différentes tailles tant que le nom contient la taille du fichier de la même manière, par exemple myimage-2048ko.jpg.

Dynamique

Les objets de test dynamiques sont utilisés pour mesurer les performances associées aux services d’accélération de site. Chacun est un fichier HTML contenant du JavaScript capable de collecter des horodatages de l’API Navigation Timing et de les publier sur la page parente. Le client télécharge l’objet de test à l’aide d’une iframe et obtient ces horodatages, qu’il utilise pour calculer les mesures.

Sécurité et validation

L’objet de test est un objet de 40 Ko. Une nouvelle fonctionnalité de l’objet de test est un HMAC (code d’authentification de message basé sur le hachage) qu’il fournit basé sur les paramètres de requête et une clé secrète à laquelle le serveur a accès. Ce HMAC est renvoyé avec notre mesure, ce qui nous permet de valider que le client Radar a pu accéder à l’objet de test et que rien n’a été mis en cache.

Différence entre les objets de test dynamiques et standard : Pour les mesures Radar standard, nous essayons d’isoler uniquement l’activité de requête principale associée au téléchargement des objets de test, tandis que pour les services d’accélération de site, notre objectif est de mesurer davantage l’activité. Par conséquent, le temps de résolution DNS et le temps de connexion sont également inclus. De plus, les mesures dynamiques sont destinées à mesurer les performances de la requête lors de l’accès à l’origine du service, et non seulement à un cache de périphérie.

Dans le portail, vous pouvez choisir cette méthodologie en procédant comme suit :

• Dans le menu de navigation de gauche, accédez à Plateformes.
• Cliquez sur l’icône Ajouter une plateforme dans le coin supérieur droit de la page.
• Accédez à Plateforme privée > Catégorie > Contenu dynamique.
• Dans la boîte de dialogue Objets de test Radar, cochez la case Personnaliser les sondes.
• Saisissez l’URL du Temps de réponse et choisissez Page web dynamique dans la liste déroulante Type d’objet.

Le petit objet de test dynamique est utilisé pour mesurer la disponibilité et le temps d’aller-retour en utilisant la même sonde pour les services d’accélération de site.

iNav

L’objet de test iNav est un fichier HTML statique contenant du JavaScript capable d’effectuer un certain nombre de tâches. Le client indique la tâche qu’il souhaite effectuer en incluant des paramètres de chaîne de requête dans l’URL qui charge le fichier HTML dans une iframe. L’objet de test iNav prend en charge les cas d’utilisation suivants : Démarrage à froid iNav Temps d’aller-retour iNav

iUNI

L’objet de test iUNI est utilisé pour détecter la valeur UNI associée à un ensemble de mesures Radar pour une plateforme (l’autre méthode étant CORS AJAX qui ne nécessite pas d’objet de test séparé).

AJAX GET

La méthodologie AJAX GET peut généralement être utilisée avec n’importe quelle URL que le client souhaite mesurer, à condition qu’elle soit servie avec l’en-tête Timing-Allow-Origin et un en-tête Access-Control-Allow-Origin approprié. Dans le portail, vous pouvez choisir cette méthodologie en procédant comme suit :

• Dans le menu de navigation de gauche, accédez à Plateformes.
• Cliquez sur l’icône Ajouter une plateforme dans le coin supérieur droit de la page.
• Accédez à Plateforme privée > Catégorie > Contenu dynamique.
• Dans la boîte de dialogue Objets de test Radar, cochez la case Personnaliser les sondes.
• Saisissez le Temps de réponse et choisissez AJAX (GET) dans la liste déroulante Type d’objet.

En-tête Timing-Allow-Origin

L’en-tête de réponse Timing-Allow-Origin est requis pour permettre l’accès JavaScript aux données de temporisation de bas niveau fournies par l’API Resource Timing. Le paramètre recommandé est Timing-Allow-Origin: *, ce qui indique que l’autorisation d’accéder aux données de temporisation de la ressource doit être accordée au JavaScript s’exécutant sur n’importe quel domaine.

API Radar

Radar fournit des API pour les fonctions opérationnelles et de récupération de données.

• API d’opérations – Ajouter/Modifier/Supprimer des comptes Radar et les mécanismes de contrôle pour gérer votre compte via une API.

• API de données Radar – L’API de données ITM Radar fournit des agrégats des données de mesure publiques communautaires et privées de Radar. Les données sont mises à jour en continu et regroupées toutes les 60 secondes environ pour être récupérées par l’API. L’API de données est fournie pour permettre aux clients d’intégrer les données Radar dans leurs propres rapports et tableaux de bord. Un seul appel à l’API peut fournir des moyennes de mesure Radar par quartile ou moyenne pour tous les pays et jusqu’à 30 ASN d’intérêt, pour chaque plateforme.

Rapports Radar

Les rapports Radar offrent une visibilité puissante sur les données dynamiques collectées via la balise Radar.

Les membres Radar ont accès à un ensemble de données riche présenté via des graphiques interactifs intuitifs. L’ensemble de données collectées intègre à la fois l’ensemble complet de données publiques de milliards de mesures comme contexte pour les données privées collectées à partir de la balise Radar d’un client ou du déploiement d’un SDK mobile. Les informations sur le temps de chargement des pages sont capturées avec la propre balise du client, offrant un aperçu approfondi de l’expérience de performance réelle de vos utilisateurs finaux de sites web et d’applications mobiles.

En plus des métriques de performance, les rapports Radar fournissent un aperçu de nombreux aspects de votre audience d’utilisateurs finaux, y compris : les volumes, les zones géographiques, les agents utilisateurs, les types de systèmes d’exploitation et le moment de leur utilisation de votre site web ou application mobile.

Chaque rapport est défini ci-dessous, mais voici les aspects importants de tous les rapports :

Dimensions principales et secondaires

La dimension principale du graphique est sélectionnée via une liste de sélection au-dessus du graphique. Utilisez-la comme un puissant pivot sur le rapport. Une dimension secondaire peut également être choisie pour affiner davantage le rapport.

Bascule d’arrière-plan de la visualisation

Les graphiques ont un arrière-plan blanc par défaut. Basculez l’arrière-plan vers une couleur sombre pour les moniteurs à contraste élevé à l’aide de la bascule d’arrière-plan.

Exportation des données

De plus, l’utilisateur final peut télécharger les données du graphique et du tableau via le lien de téléchargement situé en haut du rapport.

Filtre : Plage de temps du rapport

Les rapports Radar peuvent être générés avec une plage de temps de 60 dernières minutes, 24 dernières heures, 48 dernières heures, 7 derniers jours, 30 derniers jours, ou une plage personnalisée. La vue par défaut est les 24 dernières heures.

Filtre : Plateforme et emplacement

Les rapports varient légèrement en fonction des filtres appropriés basés sur les données. Voici les plus courants :

• Plateforme – Sélectionnez une ou plusieurs plateformes (fournisseur) à inclure.
• Continent – Sélectionnez un ou plusieurs continents à inclure.
• Pays – Sélectionnez un ou plusieurs pays à inclure.
• Région – Sélectionnez une ou plusieurs régions géographiques (le cas échéant) à inclure.
• État – Sélectionnez un ou plusieurs états géographiques (le cas échéant) à inclure.
• Réseau – Sélectionnez un ou plusieurs réseaux (ASN) à inclure.

Filtre : Ressources

• Source de données – Incluez les données de l’ensemble de la communauté Radar ou uniquement de vos visiteurs de site.
• Source d’emplacement – Sélectionnez l’adresse IP du client ou l’adresse IP du résolveur comme source d’emplacement.
• Type de client Radar – Sélectionnez le type de client Radar comme balise JavaScript, SDK iOS ou SDK Android.

Rapport de géolocalisation de mes pages vues

Ce rapport affiche le volume de pages vues pour chaque pays. Cette vue cartographique peut être consultée au fil du temps (en fonction de la plage de temps choisie pour le rapport) en sélectionnant le bouton « Lecture » en bas du graphique.

Rapport de performance

Ce rapport affiche la tendance des performances pour chacune des plateformes définies.

Rapport de distribution statistique

Ce rapport affiche la répartition statistique pour chacune des plateformes définies pour le compte.

Rapport de géolocalisation d’une seule plateforme

Ce rapport affiche la distribution du trafic Radar par pays au fil du temps pour une seule plateforme à la fois.

Rapport de distribution statistique d’une seule plateforme

Ce rapport affiche la distribution du trafic Radar au fil du temps par temps de réponse.