LIVRE BLANC AKAMAI...L'amélioration des performances passe par la mise au point d'une stratégie de test efficace. En premier lieu, il importe de comprendre la manière dont les utilisateurs

LIVRE BLANC AKAMAI

Guide complet pour tester les performances de vos sites Web et

de vos applications de vente

Table des matières

Premier pas dans le test des ressources Web et mobiles des sites de vente ........................... 1

Quels sont les défis récurrents auxquels sont confrontés les détaillants en ligne ? .............. 2

Premiers pas : liste de contrôle des tests de performances ..................................................... 2

Quels sont les indicateurs commerciaux clés de la vente au détail en ligne ? ....................... 3

Quelle est la bonne vitesse ? ..................................................................................................... 3

Qui doit intégrer votre équipe de test ? .................................................................................. 4

Quels sont les éléments à étudier lors des tests ? .................................................................... 5

Types de tests de performances ................................................................................................ 6

Comparaison entre les tests en production et les tests en laboratoire .................................. 6

Tests en laboratoire de performances ...................................................................................... 7

Tests en production (Oui, c’est possible) .................................................................................. 8

Test de la sécurité et des performances ..................................................................................10

Annexe A : La méthodologie de test de performances d’Akamai .........................................11

Annexe B : Questions-réponses sur les données de performances de CloudTest .................12

Guide complet pour tester les performances de vos sites Web et de vos applications de vente 1

Premier pas dans le test des ressources Web et mobiles des sites de venteLes détaillants exerçant dans le monde difficile du commerce en ligne doivent faire face à de

nombreux défis. Ils doivent non seulement proposer une expérience d'achat aussi attractive

qu'intéressante, mais également faire en sorte qu'elle soit rapide et fiable.

Près de la moitié des acheteurs en ligne avouent abandonner une page dès que son temps de

chargement dépasse les 2 secondes. Dans la vraie vie, un client séduit par la concurrence doit sortir

du magasin qu'il visite et se rendre physiquement dans un autre établissement qui l'attend les bras

grand ouverts. Sur le Web, les concurrents sont à portée de clic.

C'EST PROUVÉ : ACCÉLÉRER LE CHARGEMENT DES PAGES PERMET D'AUGMENTER LE TAUX DE CONVERSION ET LE CHIFFRE D'AFFAIRES.

Chez Walmart.com, toute seconde gagnée en temps de chargement équivaut à une augmentation du taux de conversion de 2 %. En réduisant le temps de chargement moyen de ses pages d'une seconde, Staples.com a amélioré son taux de conversion de 10 %.

LES SITES LENTS OU INDISPONIBLES PEUVENT AVOIR UN IMPACT NÉGATIF SUR LA FIDÉLISATION DES CLIENTS.

Le chiffre d'affaires n'est pas le seul indicateur affecté par les ralentissements et les pannes. Akamai a étudié l'impact des pannes par rapport aux ralentissements en termes de

taux d'abandon des sites de commerce au détail en ligne. Les résultats sont sans appel : les sites présentant des pannes enregistrent, en moyenne, un taux d'abandon définitif de 9 %. Les sites souffrant de ralentissements enregistrent quant à eux un taux d'abandon définitif de 28 %.

LES TESTS EN PRODUCTION SONT LE SEUL MOYEN DE S'ASSURER QUE LES APPLICATIONS EN LIGNE RÉPONDENT AUX NIVEAUX DE PERFORMANCES ATTENDUS.

Les tests externes de l'infrastructure de production sont le meilleur moyen d'évaluer la capacité et les performances réelles d'un site. (Cela ne remet pas en cause, bien sûr, l'utilité des tests en laboratoire, ni les avantages qui en découlent. Il est important d'assurer une cohérence entre ces deux types de tests.)

Alors comment être certain que votre boutique en ligne offrira une belle expérience d'achat et supportera les pics de trafic liés aux événements saisonniers, aux promotions et autres soldes ? Et comment mesurer la réussite ?

Ce guide a été rédigé pour vous aider à répondre aux questions suivantes :

• Quels sont les défis récurrents auxquels sont confrontés les détaillants en ligne ?

• Quels éléments doivent figurer sur votre liste de contrôle des tests de performances ?

• Quels sont les indicateurs commerciaux clés de la vente au détail en ligne ?

• Qui doit intégrer votre équipe de test ?

• Quels types de tests devez-vous exécuter ?

• Quels sont les éléments à étudier lors des tests ?

• Pourquoi procéder à des tests en laboratoire ? Et pourquoi réaliser également des tests en production ?

À présent, commençons !

44 %des utilisateurs affirment que la lenteur d'une transaction en ligne les fait douter de la réussite de cette transaction.


Quels sont les défis récurrents auxquels sont confrontés les détaillants en ligne ?Les boutiques en ligne travaillent dur pour concurrencer les magasins classiques. En effet, les acheteurs ont l'habitude de se rendre dans des boutiques physiques afin de voir, toucher et évaluer les produits avant de prendre une décision.

Le Web ne peut pas offrir le même niveau d'interactivité qu'un magasin, mais grâce à un large éventail de fonctionnalités (vidéos, moteurs de recommandation, avis d'utilisateurs, images haute résolution présentant les produits sous différents angles, outils permettant « d'essayer » les vêtements), les sites de vente en ligne offrent désormais une expérience d'achat inégalée.

La mise en valeur de votre marque en ligne constitue également un défi majeur. Les feuilles de style et les polices personnalisées vous permettent de contrôler la manière dont vous présentez votre marque. Cependant, ces attributs peuvent compromettre les performances et la disponibilité de votre site.

Il peut s'avérer difficile de trouver un juste équilibre entre les performances et la richesse du contenu utilisé pour atteindre un objectif donné.

Derrière la vitrine, les systèmes dorsaux chargés du traitement des paiements, des autorisations, du contrôle du stock, etc. peuvent également ralentir les performances.

Au final, nombre de ces fonctionnalités (des avis des utilisateurs aux polices personnalisées en passant par le traitement des paiements) sont créées et hébergées par des tiers. Ce contenu dote votre site de nouvelles fonctions et informations, mais ajoute également une couche de trafic et de complexité supplémentaire extrêmement difficile à contrôler.

Il est indispensable de comprendre l'impact de ce contenu pour contrôler les performances globales de votre site.

Premiers pas : liste de contrôle des tests de performancesL'amélioration des performances passe par la mise au point d'une stratégie de test efficace. En premier lieu, il importe de comprendre la manière dont les utilisateurs interagissent avec votre site de commerce en ligne.

Par exemple, les informations qui suivent sont indispensables pour définir la stratégie de test :

• Principaux processus métier (flux) suivis par les visiteurs du site

• Durée de visite moyenne des utilisateurs sur le site

• Pourcentage moyen des utilisateurs réalisant un achat par rapport aux utilisateurs se contentant de naviguer sur le site

• Taux d'abandon et étapes du processus où se produisent les abandons

• Nombres moyen et maximal d'utilisateurs simultanés par heure

• Nombres moyen et maximal de pages consultées par minute/heure

• Nombres moyen et maximal de commandes passées par minute/heure

• Différences entre les courbes des indicateurs ci-dessus pendant des événements spécifiques comme le Black Friday ou le Cyber Monday

• Provenance géographique du trafic du site

• Pourcentage du trafic mobile, types de terminaux, différences entre les flux d'utilisateurs et impact sur les indicateurs ci-dessus

• Si vous utilisez un réseau de diffusion de contenu (CDN), pourcentage de contenu diffusé à partir du CDN

Ces informations permettent de définir une stratégie de test des performances viable et influencent à la fois l'architecture et l'exécution des tests mis en œuvre.


Quels sont les indicateurs commerciaux clés de la vente au détail en ligne ? Les sites de commerce en ligne disposent d'indicateurs clés de performances qui permettent de mesurer les performances de votre site :

• Commandes par minute : pour un site de commerce en ligne, les commandes passées sur une période donnée constituent le meilleur des indicateurs clés de performances. Les commandes se répercutent directement sur le chiffre d'affaires.

• Pages consultées par heure ou minute : les clients ne peuvent terminer leur commande que si le site fonctionne. Il est essentiel de s'assurer que le site de commerce en ligne affiche le contenu Web lorsque les utilisateurs recherchent des produits, comparent et interagissent.

• Sessions par heure : les sessions correspondent aux interactions des utilisateurs particuliers ou des systèmes avec le site. Il est très important de s'assurer que ces utilisateurs puissent ouvrir et conserver une session pendant toute la durée de leur interaction.

• Erreurs : cela peut sembler évident, mais il est également indispensable de garder une trace du taux d'erreur général et du type d'erreurs reçues. Toutes les erreurs ne sont pas générées de la même manière.

• Temps de réponse moyen : il est important de connaître le temps moyen d'affichage des pages et des fichiers afin de repérer les goulets d'étranglement potentiels. C'est également l'indicateur qu'utilisent beaucoup de clients pour mesurer l'efficacité d'un site de commerce en ligne.

• Temps de réponse au 90e centile : cet indicateur offre un niveau de granularité plus fin en matière de temps de réponse. Le 90e centile supprime les 10 % de temps de réponse les plus lents. Il élimine les délais d'expiration (qui durent en moyenne 120 secondes) et donne un bon aperçu de la réponse obtenue par 90 % des utilisateurs.

Quelle est la bonne vitesse ?Un site de commerce en ligne recherchant de bonnes performances doit proposer un temps de réponse moyen inférieur à 3 secondes, avec un temps de réponse au 90e centile inférieur à 2,75 secondes.

Un détaillant souhaitant faire figurer son site parmi les meilleurs en termes de performance doit connaître la vitesse à atteindre.

Il est toutefois important de noter que les attentes des clients varient selon le type de page consultée. Par exemple, un utilisateur navigant sur un site souhaitera bénéficier d'un temps de réponse ultra-rapide, mais acceptera que la dernière étape du processus de paiement soit un peu plus lente.

Si un site de vente en ligne parvient à conserver un niveau de performances cible lors des tests à 150 à 200 % de la charge maximale attendue, il pourra traverser toutes les fêtes de fin d'année et toutes les périodes promotionnelles avec une sérénité absolue.


Qui doit intégrer votre équipe de test ?Il est essentiel de confier l'exécution du test aux bonnes personnes.

Lorsque toutes les personnes appropriées sont réunies, les tests s'avèrent nettement plus productifs. En cas de problème, le fait de disposer d'une équipe compétente et réactive permet de résoudre rapidement les difficultés et de prendre des décisions en fonction des informations disponibles.

La taille de votre entreprise et de votre personnel, l'échelle du site, la complexité du test, l'externalisation ou non du développement ou le déploiement d'applications tierces au sein de votre site, l'utilisation d'un fournisseur de services gérés pour l'infrastructure et bien d'autres facteurs, influencent le nombre de personnes à intégrer à l'équipe de test.

Dans certains cas, seules une ou deux personnes se chargent de tout. Dans d'autres cas (ex. : reconstruction complète d'un site, test d'un célèbre site en vue des fêtes, etc.), l'équipe devra intégrer de nombreuses personnes aux compétences diverses et variées, des architectes aux contributeurs individuels en charge des divers éléments de l'infrastructure.

Une stratégie de test réussie couvre de nombreux enjeux :

• Coordination : la coordination des activités de test avec les principales parties prenantes. Parmi elles figurent les ingénieurs d'application, les responsables opérationnels, les fournisseurs et les services tiers connectés, mais aussi les responsables commerciaux et la direction.

• Communication : la communication des résultats du test, des problèmes, des plans de résolution des problèmes et de la progression par rapport à la stratégie générale auprès des responsables commerciaux et de la direction.

• Stratégie : la définition d'une stratégie générale incluant la mise en place des processus des applications, les indicateurs clés de performances, les plans de capacité, la surveillance de la couverture ainsi que des programmes de test individuels conçus dans le cadre de la gestion des performances du cycle de développement du logiciel.

• Architecture : la mise en œuvre de meilleures pratiques pour créer des architectures d'application et d'infrastructure hautement performantes, que ce soit pour les nouveaux projets ou pour améliorer les applications existantes.

• Création du test : la transformation des définitions des processus métier en tests exécutables, permettant de créer des charges de travail tests afin d'évaluer les performances par rapport aux plans de capacité et de conserver en continu un historique de ces tests.

• Exécution du test : l'exécution de tests de performances continus dans le laboratoire de performances et dans l'environnement de production, puis la communication des résultats de ces tests.

• Analyse : l'étude des résultats des tests dans tous les environnements et l'analyse des performances par rapport aux tests précédents. Inclut l'identification des critères de réussite non atteints, des seuils des indicateurs clés de performances susceptibles d'être dépassés ou des écarts par rapport aux tests de référence précédents.

• Diagnostic : analyse des causes d'origine des problèmes de performances susceptibles de se produire. Inclut l'utilisation de connaissances relatives au domaine et d'outils spécialisés tels que des profileurs, des détecteurs de fuites de mémoire et d'outils de surveillance pour identifier les zones problématiques.

• Réglage : le réglage inclut la mise en œuvre des meilleures pratiques, des recommandations d'ajustement et l'identification des éléments de l'application ou de l'infrastructure pouvant être optimisés pour offrir une meilleure capacité ou des performances supérieures.

• Mesure : la responsabilité d'analyser les activités et leur progression par rapport à la stratégie générale, mais aussi de proposer des recommandations d'amélioration des processus afin d'optimiser toutes les activités stratégiques ou tactiques.

Dans les petites entreprises, toutes ces responsabilités sont confiées à une seule personne, souvent assistée par Akamai, pour la stratégie, la création, l'exécution et l'analyse du test.


Une partie ou l'intégralité des tâches peuvent être externalisées, en général pour bénéficier d'une expertise supplémentaire, se concentrer sur les zones négligées et/ou pour réduire les coûts.

Les profils et les postes sont généralement mélangés. Par exemple, la présence d'un responsable de projet, d'ingénieurs en charge des performances et/ou de spécialistes permet de ne pas faire appel à un responsable technique, qui peut alors se consacrer à d'autres tâches du processus. Voici les postes/fonctions généralement impliqués avec leurs responsabilités respectives :

• Responsable de projet : coordination, communication

• Responsable technique : coordination, communication, stratégie, architecture, analyse, diagnostic, réglage, mesure

• Architecte : architecture des infrastructures, architecture des applications

• Ingénieur en performances : stratégie, architecture, analyse, diagnostic, réglage, mesure

• Ingénieur de test : création du test, exécution, analyse

• Spécialiste : diagnostic, réglage

Quels sont les éléments à étudier lors des tests ?Comprendre ce qui fait la rapidité ou la lenteur d'un site de vente en ligne permet de se concentrer sur les éléments à tester.

De nombreux sites de commerce en ligne sont complexes et intègrent un grand nombre de composants et de niveaux d'application différents. Il est important de bien connaître chacun de ces composants et de savoir comment ils interagissent entre eux.

Les domaines sur lesquels concentrer les tests sont généralement les suivants :

• Problèmes au niveau de l'application : il n'existe pas de code parfait. Recherchez les lignes de code inefficaces, les problèmes de synchronisation, la récupération de l'espace mémoire, les fuites de mémoire et les blocages de l'application.

• Performances de la base de données : c'est le cœur même des performances d'un site. Recherchez les blocages, les conflits et les index manquants, étudiez les requêtes inefficaces, la gestion de la mémoire, la gestion de la connexion et l'accroissement non maîtrisé des données.

• Paramètres de configuration : les paramètres par défaut sont rarement les meilleurs. Recherchez les différences entre les environnements et étudiez les options de réglage et les meilleures pratiques selon les appareils composant l'architecture.

• Équilibrage de la charge : utilisez efficacement le matériel. Recherchez les algorithmes non optimisés et les fonctionnalités et capacités sous-utilisées.

• Connectivité : la communication est vitale. Vérifiez que les systèmes communiquent avec une latence minimale, que le pare-feu possède une capacité suffisante, que le système est optimisé pour les réseaux mobiles, que le routage DNS est correct et que la mise en cache du CDN est optimisée.

• Bande passante : peut-on accéder à votre site ? Vérifiez que le débit de la bande passante est suffisant pour le trafic. Étudiez le contenu des pages. Un contenu riche peut se révéler très gourmand en termes de Big Data et de bande passante. Vérifiez que le site peut prendre en charge divers types de connexions/débits, et notamment les terminaux mobiles.

• Architecture : le moteur doit être adapté à la voiture. Vérifiez s'il existe un déséquilibre entre les niveaux d'application, des problèmes de compatibilité entre les technologies ou si la capacité de montée en charge est insuffisante à terme.

• Services tiers : vous ne pouvez pas aller plus vite que les ressources les plus lentes de vos pages. Vérifiez que les outils d'analyse et de suivi, les systèmes de paiement, le contenu global, les réseaux sociaux ou les CDN ne ralentissent pas votre site.


Types de tests de performancesUne question revient souvent : « Quels types de tests doivent être réalisés ? ».

Il existe plusieurs options de tests : référence, contrainte, pic, endurance et basculement. Pour un détaillant, toutes ont un intérêt.

RéférenceLes détaillants doivent définir ce qu'ils considèrent comme un niveau de performance acceptable lorsque leur site est soumis à une « charge moyenne ». Nous recommandons d'analyser le trafic des six derniers mois à l'heure la plus chargée et d'utiliser cette valeur comme charge moyenne des pages consultées par heure et des commandes passées par minute.

ContrainteLes détaillants doivent réaliser des tests de contrainte pour s'assurer que les performances de leur site ne se dégradent pas en cas de forte sollicitation pendant une durée prolongée. Il n'est pas rare que des fuites de mémoire ou des récupérations incorrectes de l'espace mémoire entraînent des problèmes de performance qui ne peuvent être détectés sans réaliser de tests de contrainte. Akamai recommande d'exécuter les tests de contrainte à 150-200 % de la charge maximale attendue.

PicUn test de pic correspond à une augmentation ultra-rapide du nombre d'utilisateurs ou à la connexion quasi simultanée d'un très grand nombre de visiteurs. Pour les détaillants, les tests de pic sont indispensables. En effet, de nombreux événements spéciaux (promotions flash, Black Friday, Cyber Monday, Saint-Valentin, etc.) entraînent des pics de trafic pouvant mettre un site à genoux. Les détaillants doivent veiller à ne perdre aucune commande ni aucun client lors de ces événements. Akamai recommande d'exécuter les tests de pic à 200 % de la charge maximale attendue.

EnduranceLes tests d'endurance diffèrent des tests de contrainte en termes d'ampleur. Alors qu'un test de contrainte concerne un nombre très élevé de pages consultées et de commandes, un test d'endurance simule une charge légèrement moins grande, mais sur une durée plus longue. Ces tests sont très importants car ils permettent d'identifier de nouvelles zones au niveau desquelles les performances peuvent se dégrader après un certain temps (traitement par lots, sauvegardes de bases de données, opérations d'actualisation du cache planifiées et exécutées de manière récurrente, etc.) L'exécution d'un test d'endurance sur plusieurs heures peut révéler l'impact de ces types d'événements sur les performances.

BasculementLa plupart des détaillants disposent de serveurs de reprise après incident ou de basculement qui s'activent en cas de panne. Si une panne matérielle se produit pendant une période de forte sollicitation, le matériel de sauvegarde sera-t-il en mesure de prendre le relais ? Le seul moyen de le savoir est de réaliser un test de basculement.

Lors des tests préliminaires, l'objectif est souvent de comprendre les caractéristiques de performances du site. Pour ces tests, les taux d'accélération peuvent être plus lents et plus méthodiques.

Une fois les références établies et la charge pouvant être supportée par le site connue, il est essentiel que les tests soient exécutés de la manière la plus réaliste possible. Les niveaux d'utilisation et les taux d'accélération doivent se rapprocher au maximum de la réalité. L'étude de l'analyse des années précédentes peut vous aider à établir les niveaux d'accélération appropriés.

Il est impératif de ne pas tricher. Ne modifiez pas les délais de réflexion et ne supprimez pas les composants essentiels du test. Ceci reviendrait à fausser les résultats et à diminuer la valeur des tests.

Comparaison entre les tests en production et les tests en laboratoirePour tester votre réussite, vous devez établir une stratégie de test de la vente en ligne. Cette stratégie doit être mise en œuvre par une équipe compétente afin de garantir l'exécution des tests. Tester la réussite signifie comprendre la valeur des tests en production et en laboratoire de performances.

La réalisation de différents types de tests dans des environnements différents est un élément clé pour repérer et résoudre les goulets d'étranglement dans les architectures souvent complexes qui composent un site de vente en ligne.


Établissement d'un programme de test de bout en bout dont le test en production est un composant essentiel

RÉSEAU ET OPÉRATEURS

COMMERCIALISATION ET DÉPLOIEMENT

ÉTAP

E ET

ÉQ

UIP

E

SCALE OF TEST

DÉVELOPPEMENT ET TEST

LABORATOIRE DE TEST STAGING PRODUCTION (100 %+++)

Lenteur des pages

Fuites de mémoire

Récupération de l'espace mémoire

Paramètres de configuration par défaut

Lenteur des plug-ins tiers

Dépassement du nombre max. de sockets

Défaillances de montée en charge automatique

Configuration de l'équilibrage de la charge

Conflit avec les autres applications

Bande passante du réseau

Configuration du réseau

Latence entre les systèmes

Ajustement des méthodes

Requêtes de la base de données inefficaces

Décompte des threads de la base de données

Ressources du serveur inadaptées

Limites de la technologie de recherche

Variation de la latence mondiale

Serveurs Web déséquilibrés

Capacité max. du pare-feu

Routage DNS

Emplacement des fichiers CDN

ÉCHELLE DU TEST

Le graphique ci-dessus illustre la manière dont les différents types de tests en laboratoire et en production permettent d'identifier des problèmes spécifiques au fil de l'optimisation des performances.

Tests en laboratoire de performancesLes tests de performances continus en laboratoire permettent aux équipes techniques en charge des applications d'évaluer les performances sur la durée et contribuent à stopper tout bug altérant les performances avant qu'il n'atteigne la production.

De plus, le laboratoire permet de tester les performances du code et les changements apportés à la configuration avant leur passage en production, en dehors du cycle de développement normal. Ceci peut inclure la correction rapide des bugs d'une page ou un changement de configuration mineur en apparence, mais susceptible d'avoir un impact significatif sur les performances. Très souvent, les changements de ce type sont déployés sans test ou presque et se révèlent ensuite être une source de problèmes de performances.

Les tests en laboratoire permettent en outre d'arrêter le système sans se soucier des conséquences pour les utilisateurs.

Il est important de comprendre la manière dont votre site de commerce en ligne réagit en cas de panne et fonctionne en cas de reprise. Personne ne souhaite provoquer la panne d'un site de production actif.


La méthodologie CloudTest d'Akamai est une stratégie de test des performances et d'assurance qualité logicielle dotée d'un ensemble de processus légers garantissant que les applications sont prêtes à supporter les pics d'affluence

Méthodologie CloudTest d'Akamai

Stratégie Mise en œuvre Exécution Mesure

Définition Ressources humaines

Définition Analyse

Intégration Processus Conception

Test

Évaluation

Ajustement

Tests en production (Oui, c'est possible)Le seul moyen de pouvoir faire totalement confiance à un site est de le tester en situation réelle.

Étant donné le nombre impressionnant d'utilisateurs visitant un site à un instant donné, très peu d'entreprises ont les moyens de reproduire un environnement de production dans un environnement de Staging ou un laboratoire de performances. Les tests en production sont la meilleure solution pour obtenir un aperçu des capacités et des performances d'un site en situation réelle. Ils sont également le seul moyen de vérifier que les applications en ligne réagissent conformément aux attentes.

Jusqu'à présent, les tests extrapolaient le fait que les applications testées sur quelques serveurs en laboratoire peuvent supporter des volumes de charge beaucoup plus élevés en production. Cependant, sans test précis, ces suppositions entraînent inévitablement des problèmes inattendus.

CERTAINS PIÈGES NE PEUVENT ÊTRE DÉCOUVERTS QUE LORS DES TESTS EN PRODUCTION

Voici une courte liste des problèmes ne pouvant pas être détectés au cours des tests en laboratoire :

• Les traitements par lot non présents en laboratoire (rotations des journaux, sauvegardes, etc.) ou l'impact d'autres systèmes en ligne affectant les performances

• Les problèmes de performance liés à l'équilibrage de la charge, comme des paramètres d'algorithme mal configurés

• Les problèmes de configuration du réseau (ex. : paramétrage de 100 Mo au lieu de 1 Go au niveau des commutateurs) et les problèmes de routage

• Contraintes de bande passante

• Pipeline de données non configuré pour être extensible et gérer les pics de trafic

• Latence entre les systèmes, à l'intérieur et à l'extérieur des applications

• Serveurs d'application ou serveurs Web mal configurés

• CDN non configuré pour gérer le nouveau contenu

• Performances radicalement différentes en fonction de la taille de la base de données


FOURNISSEUR DE RÉSEAU DE DIFFUSION DE CONTENU (CDN)

La grande majorité des laboratoires de test ne disposent pas d'un CDN dans le cadre de leur infrastructure. Il est donc impossible de tester la manière dont le CDN affecte les performances sans procéder à des tests en production.

Lorsqu'une entreprise de commerce de détail effectue des tests en production, elle peut tester de manière exhaustive les capacités de mise en cache/délestage de son CDN. Il est essentiel de comprendre les véritables performances d'un environnent de production.

Lors de la préparation d'un test en production, il est impératif d'impliquer le fournisseur du réseau de diffusion de contenu (CDN) à un stade précoce du processus pour s'assurer que le test aura le soutien du fournisseur de CDN. (Akamai a développé un ensemble de meilleures pratiques en matière de test incluant les ressources des CDN.)

L'un des clients d'Akamai, un ingénieur en performances travaillant pour un détaillant qui réalise un chiffre d'affaires de plusieurs milliards de dollars, considère que l'intégration d'un CDN est un élément essentiel aux tests en production :

« Lorsque nous effectuons des tests en production, la mise en cache d'Akamai est généralement activée. Ceci influence indubitablement les tests au niveau du nombre de requêtes atteignant l'origine (le site principal) et du temps de réponse, selon la provenance de la diffusion des pages : Akamai ou le site d'origine. En laboratoire, nous n'incluons généralement pas Akamai. Il nous faut donc inclure le CDN dans nos tests en production pour avoir une idée de nos performances réelles en production. »

CONTENU TIERS

De nombreux sites de vente en ligne font appel à des fournisseurs tiers pour améliorer le contenu général de leur site. Il est essentiel d'impliquer ces fournisseurs tiers susceptibles d'avoir un impact sur les performances lors de l'élaboration de la stratégie.

En revanche, il n'est pas nécessaire d'intégrer des domaines tels que Google Analytics ou les indicateurs Omniture à votre test. Car ces sociétés ne souhaitent pas être surprises par un test ou voir leur service ou site interrompu par des transactions factices.

L'implication de fournisseurs tiers à un stade précoce du processus contribue à garantir leur soutien. Il se peut même qu'ils souhaitent être évalués au passage. Après tout, eux aussi souhaitent disposer d'un site performant !

IMPACT POTENTIEL SUR LES CLIENTS CONNECTÉS

Les tests en production peuvent être réalisés que des clients soient connectés ou non à l'environnement. (Remarque : la majorité des clients réalisant des tests en production avec le CloudTest d'Akamai le font dans un environnement connecté.)

Il est possible, bien que ce ne soit pas systématiquement réalisable, d'afficher une page de maintenance ou temporaire et d'attendre que toutes les sessions utilisateur existantes soient terminées. En réalité, cette méthode est rarement utilisée car en associant l'outil et la méthodologie appropriés, il est possible de réaliser les tests lorsque des utilisateurs sont actifs sur le site, et ceci dans la plupart des cas, hormis les plus extrêmes.

Pour reprendre les mots exacts d'un client d'Akamai : « Le coût de l'absence de tests est beaucoup plus élevé que leurs conséquences potentielles sur les clients connectés. »

De plus, vous pouvez continuer à gagner de l'argent tout en réalisant les tests... à condition d'utiliser la bonne approche. Il est également possible d'isoler une partie de l'environnement connecté lorsque le trafic est faible pour tester ce sous-environnement, ou de tester un centre de données pendant que les utilisateurs connectés sont redirigés vers un autre centre de données.

Pour cela, une adresse IP distincte doit être configurée sur un dispositif d'équilibrage de la charge et les serveurs doivent être déplacés du pool actif vers le pool de test. Des changements de configuration doivent parfois être apportés à d'autres composants partagés. Cette approche est plus onéreuse en raison du matériel supplémentaire nécessaire et des frais de maintenance occasionnés. Elle est également légèrement moins fiable, car elle s'éloigne quelque peu de la configuration de production réelle et ne permet pas d'effectuer les tests à la véritable échelle. Elle est toutefois beaucoup plus réaliste que les simples tests en laboratoire.


LES TROIS CONDITIONS REQUISES POUR RÉUSSIR SES TESTS EN DIRECT

1. Un système d'analyse en temps réelLa première condition requise pour procéder à un test en direct à grande échelle avec des clients connectés est que votre outil de test intègre un système d'analyse en temps réel. Grâce à des informations quasi instantanées sur les performances du site, vous pouvez rapidement voir si un site commence à proposer une expérience médiocre ou cesse de répondre.

2. Un bon coupe-circuitVous devez disposer d'un bouton « Stop » ou « Annuler » pour arrêter immédiatement la charge lors d'un test de performance. La bande passante, les connexions simultanées, les threads utilisés et tous les autres problèmes classiques reviennent alors à la normale.

3. Des pratiques de surveillance internes éprouvéesPour finir, disposer de bonnes pratiques de surveillance internes, de préférence intégrées à votre solution de test, peut vous empêcher de devoir mettre fin à un test en direct en raison de ses conséquences pour les utilisateurs connectés. La visibilité en temps réel sur des indicateurs comme l'utilisation du processeur, de la pile, la récupération de l'espace mémoire et le nombre de connexions au niveau des dispositifs d'équilibrage de la charge ou des pare-feu peut contribuer à empêcher le dépassement de ces seuils par les tests de routine.

Test de la sécurité et des performancesPersonne ne prête attention à la sécurité tant que tout va bien. On entend rarement parler dans les journaux d'entreprises qui réussissent à parfaitement garantir la sécurité des données de leurs clients. Par contre, les récits de sociétés qui laissent filer les données de leurs clients entre de mauvaises mains sont légion.

La sécurité des données est l'un des enjeux majeurs des tests de performances. Aucune entreprise ne souhaite que ses données confidentielles ne sortent du périmètre du pare-feu.

Pour une sécurité optimale, vos tests de performance doivent :

• générer des données synthétiques ou utiliser des données nettoyées, en fonction de votre entreprise et de vos exigences de sécurité ;

• relever uniquement les indicateurs HTTP/HTTPS clés et les données statistiques à des fins de compilation de rapports, d'analyse et de diagnostic ; et

• disposer de règles de sécurité rigoureuses permettant d'assurer la sécurité de vos données.

En revanche, ils ne doivent pas :

• vous demander d'exporter vos données ou vos applications en dehors du périmètre du pare-feu ; ni

• enregistrer le contenu généré sur les serveurs de test ou dans la base de données des résultats.


Annexe A : La méthodologie de test de performances d'Akamai

La méthodologie d'Akamai consiste à exécuter différents tests à différents endroits pour trouver l'aiguille dans la botte de foin.

MÉTHODOLOGIE CLOUDTEST D'AKAMAI

La méthodologie de test de performances d'Akamai est une stratégie de test des performances et d'assurance qualité logicielle dotée d'un ensemble de processus légers s'insérant dans le cycle de développement du logiciel, qui garantit que les applications sont prêtes à supporter les pics d'affluence. La méthodologie inclut des applications de test en laboratoire au sein du pare-feu ainsi que des processus de test de l'infrastructure de production utilisée par les clients.

Les tests cloud tirent parti de l'efficacité du cloud pour tester les applications et les sites Web. Grâce à l'infrastructure et aux services d'entreprises comme Amazon Web Services et Rackspace, les clients d'Akamai peuvent réduire le coût de leurs tests de charge et de performances tout en obtenant un aperçu précis du trafic réel sur le site. CloudTest est une architecture distribuée pouvant également être complètement déployée derrière le pare-feu, ou dans une combinaison de configurations sur site et dans le cloud.

Basée sur des années d'expérience de test sur le cloud, des meilleures pratiques et des méthodologies de test de performance éprouvées, la méthodologie d'Akamai dépasse les approches traditionnelles pour saisir de nouvelles opportunités et répondre à de nouveaux défis. Ces derniers incluent notamment :

• Des tests en laboratoire et sur les applications Web en production

• L'exploitation du cloud pour tester aussi bien les niveaux de trafic types que les pics, de quelques centaines à plusieurs millions d'utilisateurs

• La réponse à l'accélération des cycles de développement en faisant des tests de performance agiles une alternative réaliste

• La génération d'une charge dispersée géographiquement, pour représenter le trafic réel le plus précisément possible

• La génération de charges interne et externe à la fois en laboratoire et en production pour obtenir les résultats les plus efficaces et précis possibles

• L'analyse d'informations sur les performances en temps réel pour accélérer la résolution des problèmes

STRATÉGIE ET PLANIFICATION

L'approche d'Akamai en matière d'amélioration des performances nécessite une stratégie globale intégrant des programmes de test individuels.

Les programmes de test s'inscrivent dans une perspective globale qui garantit le fonctionnement continu des applications génératrices de revenus.

Ensemble, ils forment une stratégie d'amélioration des performances continue qui s'adapte à l'évolution du site.

Ceci implique de disposer d'un certain nombre de programmes de test centrés sur des objectifs individuels comme la préparation aux événements saisonniers, un changement architectural majeur ou la publication d'une nouvelle version du code.

En utilisant une stratégie bien définie et des programmes de test explicites, les dirigeants d'entreprise et les responsables techniques peuvent organiser la préparation opérationnelle de leurs sites en toute confiance. L'utilisation de cette approche leur permet de mieux connaître les performances d'une application.

L'emploi d'un processus itératif au sein des programmes de test pour atteindre des objectifs définis permet en outre d'améliorer en permanence les applications testées.

Ceci commence par la définition du test et aboutit à des résultats exploitables.

Tout processus de création d'un programme de test débute par une phase de définition. C'est durant cette phase que les flux à tester sont définis, que les indicateurs à surveiller sont déterminés et que les critères des tests sont identifiés. Au cours de la phase de conception, les différents scénarios utilisateurs sont écrits et les paramètres du test configurés. Les éléments tels que la proportion d'utilisateurs exécutant différentes parties de l'application, les cibles d'utilisateur virtuel et le temps de préparation sont modélisés.


La phase de test correspond au moment où les tests sont véritablement exécutés, et où les données sont recueillies à des fins d'évaluation.

Pour finir, la phase d'évaluation, dont une part peut démarrer pendant l'exécution du test, est la phase au cours de laquelle les données collectées tout au long de l'exécution du test sont utilisées pour fournir des informations exploitables.

Annexe B : Questions-réponses sur les données de performances de CloudTest

QU'EST-CE QUE LES DONNÉES DE PERFORMANCES ?

De nombreux types de données de performances sont utilisés dans le cadre des tests de performances. Les données de performances se divisent en trois catégories principales : les données maîtres, les données générées par les utilisateurs et les données externes. Les données maîtres se trouvent généralement dans la ou les bases de données du client et sont nécessaires pour mener à bien les activités commerciales (noms d'utilisateur, mots de passe, etc.). Les données générées par les utilisateurs représentent tout ce que les utilisateurs saisissent dans les champs modifiables de l'application (nouvelle adresse e-mail, nouvelle adresse, etc.). Les données externes sont fournies au moment de l'exécution de l'application (numéros de confirmation, ID de session, etc.).

QUELLES SONT LES DONNÉES UTILISÉES AU COURS DES TESTS ?

Les données utilisées dépendent de l'application et des processus de l'entreprise testés. Par exemple, un site statique peut ne pas nécessiter l'utilisation de données de performances, mais exiger l'accès au site pour envoyer des requêtes. Une application plus complexe peut quant à elle avoir besoin des trois types de données de performances.

QU'ADVIENT-IL DES DONNÉES DE RÉPONSE REÇUES ?

Toutes les données de réponse liées aux clients sont supprimées des serveurs CloudTest lors des tests de charge. Seules les données de performance liées aux données de réponse sont conservées (temps de réponse, erreurs, etc.). De plus, comme indiqué précédemment, les serveurs CloudTest ne sont que des instances temporaires supprimées après chaque test, et seuls les indicateurs de performance sont conservés dans la base de données des résultats. Toutefois, toutes les données relatives aux clients et les données externes sont enregistrées sur le serveur CloudTest lors de la création du script et du débogage. Les données utilisées pour créer les scripts peuvent être effacées après la création du script pour garantir qu'aucune donnée client n'est stockée sur les serveurs Akamai.

COMMENT SONT GÉRÉS LES FICHIERS JOURNAUX OU LES AUTRES INDICATEURS CONTENANT DES INFORMATIONS SUR LES DONNÉES ?

Akamai ne conserve ni les fichiers journaux ni aucun indicateur contenant des informations sur les données clients lors des tests de charge. Toutefois, comme indiqué précédemment, nous stockons ce type de données au cours de la création du script.

QUELLES SONT LES DONNÉES RENVOYÉES AUX SERVEURS CLOUDTEST ?

Au cours des tests de charge, seules les données externes clés sont conservées, comme les codes de réponse HTTP, les cookies, les ID de session, etc. Toutes ces données sont renvoyées aux serveurs CloudTest pour y être analysées, puis sont entièrement supprimées de tous les serveurs Akamai.

QUELLE EST LA DIFFÉRENCE ENTRE DES DONNÉES NETTOYÉES ET DES DONNÉES SYNTHÉTIQUES ?

Les données nettoyées résident dans la base de données d'un client et ont subi un traitement pour ne plus inclure aucune donnée client réelle ; il s'agit, par essence, des données ayant été transformées et/ou créées à partir des données de clients réels. Les données synthétiques sont générées intégralement et sont conçues pour offrir une représentation précise

de la base de données de production du client.

COMMENT SONT CRÉÉES LES DONNÉES SYNTHÉTIQUES ?

Akamai travaille en étroite collaboration avec votre équipe en charge des applications pour créer un riche volume de données représentatives. Des données sont également créées pour cibler le processus d'entreprise testé. Elles peuvent s'enrichir au fur et à mesure de l'évolution des tests.


Nous aidons les entreprises comme Apple, Target, Etsy et Microsoft à tester, surveiller et optimiser

en permanence leurs applications Web et pour mobile.

Nous pouvons vous aider aussi.

Découvrez CloudTest dès aujourd'hui !

Plateforme de diffusion dans le cloud la plus fiable et la plus utilisée au monde, Akamai aide les entreprises à fournir à leurs clients des expériences numériques optimisées et sécurisées sur tous types de terminaux, à tout moment et partout dans le monde.La plateforme massivement distribuée d'Akamai bénéficie d'un déploiement inégalé avec plus de 200 000 serveurs dans 130 pays, offrant ainsi aux clients des niveaux avancés de performances et de protection contre les menaces.Les solutions de diffusion vidéo, d'accès professionnel, de sécurité dans le cloud et de performances Web et mobiles d'Akamai s'appuient également sur un service client exceptionnel et une surveillance 24 h/24 et 7 j/7.Pour découvrir pourquoi de grandes institutions financières, des leaders du e-commerce, entreprises du divertissement et des médias et des organisations gouvernementales font confiance à Akamai, consultez les sites www.akamai.com/fr, blogs.akamai.com ou suivez @Akamai sur Twitter. Vous trouverez nos coordonnées dans le monde entier à l'adresse www.akamai.com/locations. Publication : 07/17.

QU'ADVIENT-IL DES DONNÉES UNE FOIS LES TESTS TERMINÉS ?

Une fois les tests terminés, les serveurs CloudTest conservent uniquement les données des indicateurs de performances s'avérant pertinentes pour l'exécution des tests. Aucune donnée professionnelle n'est conservée sur les serveurs CloudTest.

COMMENT LES DONNÉES DES TESTS SONT-ELLES STOCKÉES DANS LE CLOUD ?

Les résultats des tests exécutés par Akamai sont stockés dans le cloud. Les résultats sont placés sur des serveurs Linux démantelés à la fin des tests. Ces serveurs sont uniquement disponibles pendant les sessions de test ou lors de l'analyse des résultats. Le plus souvent, les données des résultats sont stockées dans une base de données relationnelle sur une instance EC2 dans un EBS (elastic block store). Seuls les employés d'Akamai peuvent accéder à ces données.

LES DONNÉES DES RÉSULTATS DES TESTS PEUVENT-ELLES ÊTRE SUPPRIMÉES DU CLOUD ?

Oui, les résultats peuvent être effacés et supprimés du cloud à la demande du client. Dans ce cas, les résultats ne sont pas effacés tant que le rapport de résultat n'est pas terminé. La suppression des résultats est irréversible. Les résultats effacés ne sont pas sauvegardés. Notez que la suppression des résultats peut limiter votre capacité à effectuer des comparaisons avec des tests précédents ou ultérieurs. Le seul moyen de comparer les résultats supprimés consiste à consulter le rapport correspondant.

LES DONNÉES DES RÉSULTATS DES TEST PEUVENT-ELLES ÊTRE EXPORTÉES DEPUIS LE CLOUD POUR ÊTRE STOCKÉES HORS SITE ?

Oui. Tous les résultats sont exportables au format XML. Les résultats peuvent être exportés depuis le cloud et transférés vers un emplacement défini par le client à des fins d'archivage. En fonction de la longueur du test et du volume des données de performances liées au test, l'exportation de ces données depuis le cloud et leur transfert vers un emplacement sûr peut prendre jusqu'à 24/48 heures. Les résultats exportés peuvent également être supprimés du cloud.

https://www.akamai.com/fr/fr/products/web-performance/cloudtest.jsp

https://www.akamai.com/fr/fr

https://blogs.akamai.com

https://twitter.com/Akamai

https://www.akamai.com/fr/fr/locations.jsp

Documents

LIVRE BLANC AKAMAI...L'amélioration des performances passe par la mise au point d'une stratégie de test efficace. En premier lieu, il importe de comprendre la manière dont les utilisateurs