Radar

Vue d’ensemble

Le radar constitue l’épine dorsale de la méthodologie de collecte de données. Radar utilise un script JavaScript intégré à une page de contenu ou aux 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 diffusion.

Le client Radar est une application JavaScript qui s’exécute sur les pages Web des clients et dans les applications mobiles. Son objectif principal est de recueillir les données de performance du 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 de gestion intelligente du trafic NetScaler, tels que le temps de chargement des pages, le chronométrage des ressources de page et les mesures de lecture vidéo.

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 dans la mesure du possible. Ces instructions indiquent la plateforme à mesurer ensuite au cours de la session, choisie parmi les plateformes communautaires et toutes les plateformes privées spécifiques à ce membre de la communauté. Ils indiquent également les types de mesures à effectuer, qui peuvent inclure la disponibilité, le temps d’aller-retour, le débit ou d’autres collectes métriques.

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

Communauté Radar

Grâce à une approche communautaire unique, Radar apporte une transparence inégalée aux performances et à la disponibilité mondiales des plus grandes infrastructures publiques du monde, du cloud computing au stockage en passant par les réseaux de diffusion de contenu et d’applications. Grâce à 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 du cloud sur 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 fournit également un ensemble complet d’outils permettant de saisir les niveaux de service fournis par les infrastructures de diffusion de contenu internes et externes. La particularité de Radar est 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. La même méthodologie permet des évaluations objectives des plateformes cloud tout au long de leur cycle de vie, y compris une é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. Le 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 distribution et les plateformes cloud tels que vus par les utilisateurs finaux réels des sites ou des applications Web.

Principaux avantages de la participation

Radar répond à de nombreux défis liés à la diffusion Web grâce à son approche de surveillance et de collecte de données. Les principaux avantages de la participation à la communauté Radar sont les suivants :

• Environnement de test massif, avec des utilisateurs finaux sur tous les réseaux et sur tous les sites (plus de 42 000 réseaux reconnus à ce jour).
• Obtenez des informations importantes sur les fournisseurs de services avant de les tester afin de prendre une décision plus éclairée.
• Transparence des performances des fournisseurs actuels et de leur comportement dans les zones géographiques où vous avez ou n’avez pas d’utilisateurs.
• Concentrez-vous sur les indicateurs qui font une réelle différence pour les utilisateurs du Web et des appareils mobiles (performance, disponibilité et qualité de service).
• Vue globale (plus de 190 pays) des informations illimitées au niveau du pays, du réseau, de la région et de l’État.
• Des données réelles et impartiales provenant des utilisateurs finaux Les données radar sont des informations du « monde réel » plutôt qu’un test synthétique ou une meilleure estimation.
• Tous les utilisateurs ne sont pas les mêmes : comprenez les différentes machines, connexions et appareils.
• Visibilité sur les performances des pages réelles.

Points de référence

ITM Radar fournit 3 points de référence principaux :

• Analyse comparative communautaire
• Benchmarking privé
• Analyse comparative du chargement des pages

Analyse comparative communautaire du CDN, du cloud et des centres de données

Les mesures communautaires sont obtenues par le biais d’un modèle de crowdsourcing fournissant au client une vue des performances et de la disponibilité d’un fournisseur à un niveau géographique et logique à l’échelle mondiale. Les mesures communautaires permettent de comparer la qualité d’expérience d’un fournisseur telle qu’elle est perçue par l’utilisateur final et d’effectuer une analyse « hypothétique » lors de l’évaluation des fournisseurs et des fournisseurs pour la distribution de contenu et d’applications. En utilisant un modèle de crowdsourcing, les clients d’ITM bénéficient d’un meilleur niveau de granularité et de qualité des données lors de l’évaluation et du suivi des performances des fournisseurs, même dans les endroits où le client n’a pas une forte densité d’utilisateurs, voire aucun utilisateur du tout.

Les mesures elles-mêmes utilisent un ensemble standard d’objets situés dans 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 transmises à l’ITM et présentées dans les interfaces de reporting du portail ou de l’API :

• Disponibilité : que l’objet soit chargé ou non.
• Temps de réponse : temps nécessaire au serveur pour répondre à une demande 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 : débit 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 Radar Tag, ITM permet au client de créer ses propres tests « de référence » qui sont mesurés par les visiteurs du client. Cela peut être pour les centres de données ou pour leurs propres contrats CDN et cloud. Comme pour les mesures de référence de la communauté, les mêmes indicateurs sont fournis : disponibilité, temps de réponse et débit, ce qui permet au client d’évaluer efficacement une stratégie de diffusion de contenu existante.

Ces informations privées ne sont accessibles qu’au client et ne sont pas partagées. Les exemples d’utilisation incluent :

• Leur propre architecture de centre de données
• En utilisant leur propre objet de test ou leur propre page
• En utilisant leur propre contrat et compte avec un fournisseur ou un ensemble de fournisseurs spécifiques

Analyse comparative du chargement des pages Radar

Dans Radar, ITM permet au client de voir des informations détaillées sur la manière dont les pages sur lesquelles le tag est implémenté sont téléchargées. L’ITM fournit des informations qui vous permettent de voir les performances réelles des utilisateurs finaux lorsqu’ils interagissent avec vos pages Web. Les données sont fournies par le biais de l’API Navigation Timing prise en charge par de nombreux navigateurs de nouvelle version.

Balise radar

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

1. Connectez-vous au portail de gestion intelligente du trafic NetScaler.
2. Dans le menu de navigation de gauche, sélectionnez Radar > Tag Javascript.

La page Radar Tag s’ouvre.

Si vous n’avez pas encore configuré le tag Radar, une barre horizontale orange apparaît en haut de l’écran pour vous indiquer que les mesures radar n’ont pas été détectées.

Cette barre orange apparaîtra également si le tag n’a pas été configuré correctement.

Sinon, si le Radar Tag fonctionne comme prévu, une barre horizontale verte s’affiche pour vous indiquer que les mesures radar ont été obtenues avec succès.

Sur cette page, vous pouvez sélectionner la version de 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 créer un comportement inattendu ou peu fiable.

Intégration du Radar Tag

L’intégration du tag 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 body de fermeture </body>.

Tag radar par défaut

Il s’agit de 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, ce qui garantit que l’événement de chargement est ininterrompu.

<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"; // replace with user specific value
            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 le déclenchement de l’événement de chargement. Il s’adresse principalement aux clients utilisant des paramètres de politique de sécurité du contenu empêchant l’utilisation de JavaScript en ligne. Il est également destiné aux clients utilisant le plug-in Video QoS, où le client Radar doit être chargé le plus tôt possible.

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

Mesures récentes

Le tableau des mesures récentes vous permet de visualiser les dernières mesures prises à l’aide du radar.

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

• Date et heure auxquelles la mesure a été prise en UTC.
• Pays dans lequel la mesure a été prise.
• La plateforme qui a été utilisée pour effectuer la mesure.
• L’ID de la plateforme.
• Type de mesure prise, à savoir le temps de connexion (en millisecondes), le temps de réponse (en millisecondes) ou le débit (en kilobits par seconde)
• La 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 du tableau de bord radar lorsque vous vous connecterez pour la première fois au portail ITM.

Intégration aux applications mobiles

L’intégration aux applications mobiles s’effectue via des wrappers entourant des vues Web masquées qui exécutent le client JavaScript. Cela garantit la cohérence des données collectées dans les navigateurs et les applications mobiles.

Instructions pour intégrer Radar à l’application iOS Ce référentiel GitHub suivant contient le code wrapper et les instructions étape par étape pour intégrer Radar à l’application iOS :

Radar Runner pour iOS

Instructions pour intégrer Radar à Android Android Radar est une bibliothèque cliente qui facilite l’intégration de Radar dans les applications Android. Vous pouvez le trouver ici :

Bibliothèque AndroidRadar

Intégration à NetScaler

La balise Radar est importante car elle fournit à Openmix des mesures qui permettent à Openmix de prendre de meilleures décisions en matière de routage. Plus le nombre de pages Web utilisant la balise est élevé, meilleures sont les décisions de routage.

Les méthodes suivantes vous permettent de placer la balise JavaScript Radar sur 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 le tag Radar dans vos réponses. Pour injecter la balise Radar, vous devez utiliser des réécritures. Les réécritures se décomposent en trois étapes : créer des actions, configurer des politiques et lier des politiques.

Configuration en ligne de commande

Ligne de commande Configuration de l’action de réécriture

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 numéro de client là où il est écrit <customer_id>

Configuration de la politique de réécriture par la 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-->

Politique de réécriture liée à la 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 GUI

Action de réécriture de l’interface graphique

1. **Dans le menu de navigation de gauche de la page de configuration de **NetScaler, accédez à AppExpert -> Rewrite -> Rewrite Actions**

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, entrez votre numéro de client dans l’espace marqué <customer_id>.

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

Politique de réécriture de l’interface graphique

1. **Dans le menu de navigation de gauche de la page de 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 Create.

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

Politique de réécriture des liaisons de l’interface graphique

Une fois que vous avez terminé de configurer votre politique, la dernière étape consiste à lier la politique à l’aide du Policy Manager.

1. Accédez à la page des politiques de réécriture .

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

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 Bind Point, vous avez la possibilité de sélectionner Override Global, Serveur virtuel VPN, Serveur virtuelde commutation de contenu ou Serveur virtueld’équilibrage de charge.
   • Pour Protocole, sélectionnez HTTP.
   • Pour Type de connexion, sélectionnez Réponse.
   • Pour Virtual Server, utilisez votre propre nom de serveur virtuel.

   

   • Cliquez sur Continuer.
   • Sur la page suivante, sélectionnez la politique de réécriture que vous avez créée précédemment.
   • Ajoutez les détails de la reliure.
   • Cliquez sur Bind.

   

Avec les méthodes ci-dessus, vous pouvez 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 des balises radar

Vous pouvez configurer le radar sur la page de configuration des balises radar .

1. Connectez-vous au portail de gestion intelligente du trafic NetScaler.
2. Dans le menu de navigation de gauche, sélectionnez Radar > Configuration des balises.

La page de configuration des balises radar s’ouvre. Ici, vous pouvez définir différentes options pour personnaliser les mesures radar. Le JavaScript Radar comporte des 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 des mesures communautaires et privées, et les valeurs de délai pour mesurer la disponibilité, etc.

Le tableau suivant fournit des informations sur les options de configuration et les paramètres par défaut de chacune d’entre elles. Lorsque vous apportez des modifications, assurez-vous de cliquer sur Mettre à jour les paramètres du 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 session donnée, en fonction de l’emplacement de l’utilisateur final. Nous essayons de mesurer un plus grand nombre 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 maximum de mesures tentées par session. Par exemple, Radar peut mesurer 4 plateformes privées par session, toutes configurées pour mesurer à la fois le RTT et le débit. Mais si les mesures de débit privé maximum sont définies 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 chronométrage vous permettent de définir la durée pendant laquelle le radar doit attendre avant de commencer à prendre des mesures.

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

Options de protocole

Normalement, le client Radar mesure uniquement les plateformes avec des URL dont les protocoles correspondent à ceux de la page sur laquelle il s’exécute. Ces options vous permettent de modifier ce comportement pour les plateformes privées. Par exemple, l’activation de « Toujours autoriser les mesures HTTPS privées » permet au client https://myprovider.com/r20.gif de mesurer à partir de http://example.com, tandis que « Toujours autoriser les mesures HTTP privées » permet au client http://myprovider.com/r20.gif de mesurer à partir de https://example.com.

Ces options doivent généralement être évitées, sauf dans les cas d’utilisation extrêmes. Le meilleur moyen 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 « Mettre le radar là où c’est nécessaire ». «

Le taux d’échantillonnage vous permet de définir un pourcentage de pages Web (consultées par les utilisateurs) à partir desquelles des mesures seront collectées. Par exemple, si votre site Web enregistre 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 lorsque vous renvoyez des 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 de modifier le code d’urgence de votre site.

Sur la page de configuration des balises radar, désactivez les mesures privées, les mesures communautaires ou les deux en cliquant sur le bouton Activé pour désactiver.

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

mesures communautaires

Méthodologie du client Radar

La sessionest une dimension fondamentale du comportement du client. 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, appelé demande d’initialisation. Les sessions expirent assez rapidement, ce qui permet de garantir que seules les données radar valides sont acceptées. Grâce à cette fonctionnalité, les mesures radar sont toujours fournies par lots associés à leur identifiant de transaction de session, et nous faisons souvent référence à une « session radar » pour décrire les mesures qui y sont associées.

Séance radar

Une session Radar est la principale unité de travail effectuée par le client. Il consiste en une demande adressée aux serveurs NetScaler ITM pour obtenir la configuration du client et un ensemble de plateformes à mesurer, suivie de demandes visant à mesurer ces plateformes et à communiquer les résultats. Elles se déroulent de manière asynchrone et sérialisée, de sorte qu’une seule demande a lieu à la fois. Une session typique se termine en moins de 10 secondes.

Types de sondes

Chaque rapport envoyé par le client est associé à un type de sonde, qui indique au système de quel type de mesure il s’agit et comment le traiter. Il indique également les types de mesures à effectuer, qui peuvent inclure la disponibilité, le temps de trajet aller-retour, le débit ou toute autre collecte métrique. »

Il existe une relation importante entre la disponibilité et l’analyse des performances (comme le temps de trajet aller-retour et le débit). La disponibilité d’une ressource particulière est toujours mesurée en premier lors d’une session de mesure particulière. 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 au cours de cette même session. «

Si un réseau particulièrement lent subit une panne de disponibilité, cela peut entraîner une amélioration effective des performances agrégées des rapports incluant ce réseau. Il ne s’agit que d’un artefact lié au reporting, car NetScaler Intelligent Traffic Management utilise toujours les données de performance les plus détaillées et spécifiques au réseau pour prendre des 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’une valeur de mesure soit associée à cette sonde. Nous utilisons la sonde de disponibilité pour déterminer si le fournisseur est disponible.

Si une plate-forme n’est pas configurée pour effectuer une sonde de démarrage à froid, nous utilisons les résultats de la sonde RTT au lieu d’un rapport de démarrage à froid pour fournir des mesures de disponibilité.

De même, pour les objets dynamiques qui mesurent les services d’accélération du site, le client télécharge le petit objet de test une seule fois et indique 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 obligatoire :

L’en-tête de réponse Timing-Allow-Origin est requis pour permettre à JavaScript d’accéder aux données de chronométrage 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 temporelles de la ressource doit être accordée à JavaScript exécuté 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’ src attribut sur un objet Image. Une fois le téléchargement terminé, le client utilise l’API Resource Timing pour recueillir 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 Timing-Allow-Origin Header pour plus d’informations.

Standard : petit

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

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

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

Grand standard

L’objet de test standard de grande taille est un fichier image de 100 Ko utilisé pour mesurer le débit d’une plate-forme.

Dénomination 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 KB quelque part dans le nom du fichier r20-100KB.png, par exemple. Les clients peuvent mesurer des fichiers image de différentes tailles à condition que le nom indique la taille du fichier de la même manière, par exemple myimage-2048kb.jpg.

Méthode 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 code JavaScript capable de collecter des horodatages à partir de l’API de synchronisation de navigation et de les publier sur la page parent. Le client télécharge l’objet de test à l’aide d’un 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 code HMAC (code d’authentification des messages basé sur le hachage) qu’il fournit en fonction des paramètres de requête et d’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 demande principale associée au téléchargement d’objets de test, tandis que pour les services d’accélération de site, notre objectif est de mesurer davantage cette activité. Par conséquent, la recherche DNS et le temps de connexion sont également inclus. En outre, les mesures dynamiques visent à mesurer les performances des demandes lorsqu’elles atteignent l’origine du service, et pas seulement un cache périphérique.

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 en haut à droite 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 .
• Entrez l’URL du temps de réponse et choisissez Webpage Dynamic dans la liste déroulante Type d’objet .

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

en AV

L’objet de test iNav est un fichier HTML statique contenant du code 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 un iframe. L’objet de test iNav prend en charge les cas d’utilisation suivants : démarrage à froid iNav, temps aller-retour

IU

L’objet de test IUNI est utilisé pour détecter la valeur UNI associée à un ensemble de mesures radar pour une plate-forme (l’autre méthode étant CORS AJAX qui ne nécessite pas d’objet de test distinct).

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êteTiming-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 en haut à droite 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 .
• Entrez 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 afin de permettre à JavaScript d’accéder aux données de chronométrage 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 temporelles de la ressource doit être accordée à JavaScript exécuté 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 radar ITM fournit des agrégats de données de mesure publiques et privées provenant de la communauté radar. Les données sont mises à jour en continu et mises en lots environ toutes les 60 secondes 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 mesures par quartiles ou moyennes de radar pour tous les pays et jusqu’à 30 ASN présentant un intérêt, pour chaque plateforme.

Rapports radar

Les rapports radar fournissent une visibilité puissante sur les données dynamiques collectées par le biais du Radar Tag.

Les membres de Radar ont accès à un riche ensemble de données présenté sous forme de graphiques interactifs intuitifs. L’ensemble de données collecté intègre à la fois l’ensemble de données publiques complet de milliards de mesures et le contexte des données privées collectées à partir du tag Radar ou du déploiement du SDK mobile d’un client. Les informations relatives au temps de chargement des pages sont capturées à l’aide du propre tag du client, ce qui permet de mieux comprendre les performances réelles des utilisateurs finaux de votre site Web et de votre application mobile.

Outre les indicateurs de performance, les rapports Radar fournissent des informations sur de nombreuses facettes de votre public d’utilisateurs finaux, notamment : les volumes, les zones géographiques, les agents utilisateurs, les types de systèmes d’exploitation et le calendrier d’utilisation de votre site Web ou de votre 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 située au-dessus du graphique. Utilisez-le comme un puissant pivot du rapport. Une dimension secondaire peut également être choisie pour affiner davantage le rapport.

Contexte de visualisation Basculer

Par défaut, les graphiques sont définis sur un fond blanc. Basculez l’arrière-plan sur une couleur foncée pour les moniteurs à contraste élevé à l’aide de la bascule d’arrière-plan.

Export de données

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

Filtre : Période du rapport

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

Filtre : Plateforme et emplacement

Les rapports varient légèrement en ce qui concerne les filtres appropriés en fonction des données. Les plus courantes sont les suivantes :

• 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 des données provenant de l’ensemble de la communauté Radar ou uniquement des visiteurs de votre site.
• Source de localisation - Sélectionnez l’adresse IP du client ou l’adresse IP du résolveur comme source de localisation.
• Type de client Radar : sélectionnez le type de client Radar sous la forme d’une balise JavaScript, d’un SDK iOS ou d’un SDK Android.

Rapport de géolocalisation de mes pages vues

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

Rapport sur le rendement

Ce rapport montre l’évolution des performances pour chacune des plateformes définies.

Rapport de distribution statistique

Ce rapport présente la ventilation statistique pour chacune des plateformes définies pour le compte.

Rapport de géolocalisation sur une plateforme unique

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

Rapport sur la distribution statistique d’une plate-forme unique

Ce rapport montre la distribution du trafic radar dans le temps par temps de réponse.