Optimiser les performances performance-optimization

L’un des problèmes majeurs est le temps que met votre site web pour répondre aux requêtes des visiteurs et visiteuses. Bien que cette valeur varie pour chaque requête, une valeur cible moyenne peut être définie. Une fois que cette valeur se révèle à la fois réalisable et gérable, elle peut être utilisée pour surveiller les performances du site web et indiquer le développement de problèmes potentiels.

Les temps de réponse que vous visez sont différents dans les environnements de création et de publication, selon les diverses caractéristiques de l’audience cible :

Environnement de création author-environment

Cet environnement est utilisé par les auteurs et autrices qui saisissent et mettent à jour du contenu. Il doit répondre aux besoins de quelques utilisateurs et utilisatrices qui génèrent un grand nombre de requêtes lors de la mise à jour de pages de contenu et de chaque élément de ces pages.

Environnement de publication publish-environment

Cet environnement intègre le contenu que vous mettez à la disposition de vos utilisateurs. Ici, le nombre de requêtes est encore plus important et la vitesse est primordiale. Mais comme la nature des requêtes est moins dynamique, d’autres mécanismes d’amélioration des performances peuvent être appliqués, comme la mise en cache du contenu ou l’équilibrage de charge.

Méthodologie d’optimisation des performances performance-optimization-methodology

Une méthodologie d’optimisation des performances pour les projets AEM peut se résumer en cinq règles très simples qu’il convient de respecter pour éviter des problèmes de performances dès le départ :

Ces règles s’appliquent aux projets web en général et sont pertinentes pour les chefs/cheffes de projet et les administrateurs/administratrices système, car elles leur permettent d’éviter des problèmes de performances au moment du lancement de leurs projets.

Planification de l’optimisation planning-for-optimization

Planifiez environ 10 % de l’effort du projet pour la phase d’optimisation des performances. Les exigences d’optimisation des performances réelles dépendent du niveau de complexité d’un projet et de l’expérience de l’équipe de développement. Bien que votre projet puisse (finalement) ne pas nécessiter le temps alloué, il est recommandé de toujours planifier l’optimisation des performances dans la région suggérée.

Dans la mesure du possible, un projet doit d’abord être lancé en douceur pour une audience limitée, afin de collecter des données d’expérience réelle et d’effectuer d’autres activités d’optimisation, sans la pression supplémentaire qui suit une annonce de lancement définitif.

Après la « mise en production », l’optimisation des performances n’est pas terminée. C’est maintenant que vous ressentez la « vraie » charge sur votre système. Il est important de prévoir des ajustements supplémentaires après le lancement.

Comme la charge et les profils de performances de votre système changent au fil du temps, une « mise au point » ou un « contrôle de l’intégrité » des performances doivent être planifiés à 6-12 mois d’intervalle.

Simulation de la réalité simulate-reality

Si vous avez mis en ligne un site web et que vous identifiez, après le lancement, des problèmes de performances, il est probable que vos tests de charge et de performances n’ont pas simulé la réalité le plus fidèlement possible.

La simulation de la réalité est difficile et les efforts que vous êtes prêt à fournir pour vous approcher de la « réalité » dépendent de la nature de votre projet. Cette réalité signifie non seulement un « code réel » et un « trafic réel », mais aussi du « contenu réel », en particulier en ce qui concerne la taille et la structure. Vos modèles peuvent se comporter différemment selon la taille et la structure du référentiel.

Établir des objectifs solides establish-solid-goals

L’importance d’établir correctement les objectifs de performances ne doit pas être sous-estimée. Souvent, une fois que les personnes se concentrent sur des objectifs de performances précis, il est très difficile de modifier ces objectifs par la suite, même s’ils sont basés sur des hypothèses.

L’établissement d’objectifs de performances réalisables et viables est vraiment l’un des aspects les plus délicats. Il est souvent préférable de collecter les références et les données réelles d’un site Web comparable (par exemple le prédécesseur du nouveau site Web).

Maintenir la pertinence stay-relevant

Il est important de résoudre un seul goulot d’étranglement à la fois. Si vous essayez de faire des choses en parallèle sans valider l’impact d’une optimisation, vous pouvez risquer de ne plus savoir quelle mesure d’optimisation a été utile.

Cycles d’itération agile agile-iteration-cycles

L’optimisation des performances est un processus itératif qui implique des activités de mesure, d’analyse, d’optimisation et de validation jusqu’à ce que l’objectif soit atteint. Pour tenir compte de cet aspect, implémentez un processus de validation agile dans la phase d’optimisation plutôt qu’un processus de tests contraignant après chaque itération.

Cela signifie que le développeur ou la développeuse qui implémente l’optimisation doit disposer d’un moyen rapide de déterminer si l’optimisation a déjà atteint l’objectif. Ces informations sont utiles, car lorsque l’objectif est atteint, l’optimisation est terminée.

Consignes de performances de base basic-performance-guidelines

De manière générale, vos demandes html non mises en cache doivent être inférieures à 100 millisecondes. Plus précisément, ce qui suit peut servir de ligne directrice :

Les chiffres ci-dessus supposent les conditions suivantes :

Certains problèmes contribuent fréquemment aux problèmes de performances, notamment :

Le réglage au niveau de la JVM et du système d’exploitation n’entraîne généralement pas de bond en avant significatif en termes de performances et doit donc être effectué à la toute fin du cycle d’optimisation.

La structure d’un référentiel de contenu peut également avoir un impact sur les performances. Pour de meilleures performances, le nombre de nœuds enfants associés à des nœuds individuels dans un référentiel de contenu ne doit pas dépasser 1 000 (en règle générale).

Voici vos meilleurs amis lors d’un exercice habituel d’optimisation des performances :

Performances lors du chargement et de la modification des ressources numériques performance-when-loading-and-editing-digital-assets

En raison du volume important de données impliquées lors du chargement et de la modification des ressources numériques, les performances peuvent devenir un problème.

Deux éléments affectent ici les performances :

Pour améliorer les performances, tenez compte des points suivants :

Surveillance des performances performance-monitoring

Les performances (ou leur insuffisance) sont l’une des premières choses que vos utilisateurs remarquent. Aussi, pour toute application dotée d’une interface utilisateur, les performances sont un facteur déterminant. Pour optimiser les performances de votre installation AEM, vous devez surveiller les différents attributs de l’instance et son comportement.

Pour plus d’informations sur l’exécution de la surveillance des performances, consultez Surveillance des performances.

Les raisons des problèmes de performances sont souvent difficiles à détecter, même lorsque leurs effets sont faciles à voir.

Pour commencer, ayez une bonne connaissance de votre système lorsqu’il fonctionne normalement. À moins de savoir à quoi votre environnement ressemble et comment il se comporte lorsqu’il fonctionne correctement, il est difficile de localiser le problème lorsque les performances se détériorent. Passez du temps à enquêter sur votre système lorsqu’il s’exécute en douceur et assurez-vous que la collecte des informations de performances a bien lieu. Vous aurez ainsi une base de comparaison en cas de dégradation des performances.

Le diagramme suivant illustre le parcours que peut suivre une demande de contenu AEM, et donc le nombre d’éléments différents pouvant se répercuter sur les performances.

Les performances sont également un compromis entre volume et capacité :

Les performances s’illustrent à différents endroits de la chaîne web.

Plusieurs domaines fonctionnels sont souvent responsables de l’impact sur les performances :

Règles de base concernant les performances basic-rules-regarding-performance

Certaines règles doivent être prises en compte lors de l’optimisation des performances :

Configurer pour optimiser la performance configuring-for-performance

Certains aspects d’AEM (et/ou du référentiel sous-jacent) peuvent être configurés pour optimiser la performance. Vous trouverez ci-dessous des possibilités et des suggestions. Vous devez vous assurer d’utiliser la fonctionnalité en question avant d’y apporter des modifications.

Indexation de recherche search-indexing

À compter d’AEM 6.0, Adobe Experience Manager utilise une architecture de référentiel Oak.

Vous trouverez les informations d’indexation mises à jour ici :

Traitement de workflows simultanés concurrent-workflow-processing

Pour améliorer les performances, limitez le nombre de processus de workflow en cours d’exécution. Par défaut, le moteur de workflow traite autant de workflows en parallèle qu’il y a de processeurs disponibles pour la machine virtuelle Java™. Lorsque les étapes du workflow nécessitent d’importantes quantités de ressources de traitement (mémoire vive ou processeur), l’exécution simultanée de plusieurs de ces workflow peut intensifier la demande en ressources serveur disponibles.

Par exemple, lorsque des images (ou des ressources de gestion des actifs numériques en général) sont chargées, les workflows importent automatiquement les images dans la gestion des actifs numériques (DAM). Les images sont souvent à haute résolution et peuvent facilement consommer des centaines de Mo de tas pour le traitement. La gestion de ces images en parallèle place une charge élevée sur le sous-système de mémoire et le récupéreur d’espace mémoire.

Le moteur de workflow utilise les files d’attente de tâches Apache Sling pour gérer et planifier le traitement des éléments de travail. Les services de file d’attente de tâches suivants ont été créés par défaut à partir de la fabrique de services Configuration des files d’attente des tâches Apache Sling pour le traitement des tâches de workflow :

Configurez ces services pour limiter le nombre maximal de workflows en cours d’exécution.

Configuration dans le référentiel configuration-in-the-repo

Si vous configurez les services à l’aide d’un nœud sling:OsgiConfig, vous devez trouver le PID des services existants, par exemple : org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. Vous pouvez détecter le PID à l’aide de la console web.

Configurez la propriété nommée queue.maxparallel.

Configuration dans la console Web configuration-in-the-web-console

Pour configurer ces services à l’aide de la console Web, localisez les éléments de configuration existants sous la fabrique de services Configuration de la file d’attente de tâches Apache Sling.

Configurez la propriété nommée Nombre maximal de tâches en parallèle.

Configurer la file d’attente pour un workflow spécifique configure-the-queue-for-a-specific-workflow

Créez une file d’attente de tâches pour un modèle de workflow spécifique, afin de pouvoir configurer la gestion des tâches pour ce modèle de workflow. Ainsi, vos configurations affectent le traitement d’un workflow spécifique, tandis que la configuration de la file d’attente de workflow Granite par défaut contrôle le traitement d’autres workflows.

Lorsque les modèles de workflow s’exécutent, ils créent des tâches Sling pour une rubrique spécifique. Par défaut, la rubrique correspond aux rubriques configurées pour la file d’attente de workflows Granite générale ou la file d’attente de tâches de processus externe de workflows Granite :

Les rubriques de tâche réelles générées par les modèles de workflow incluent le suffixe spécifique au modèle. Par exemple, le modèle du workflow Ressource de mise à jour de la gestion des ressources numériques génère des tâches avec la rubrique suivante :

com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model

Par conséquent, vous pouvez créer une file d’attente de tâches pour la rubrique correspondant aux rubriques de votre modèle de workflow. La configuration des propriétés liées aux performances de la file d’attente affecte uniquement le modèle de workflow qui génère les tâches correspondant à la rubrique de la file d’attente.

La procédure suivante crée une file d’attente de tâches pour un workflow, en utilisant le workflow Ressource de mise à jour de la gestion des ressources numériques pour exemple.

Service AEM de synchronisation des ressources de gestion des ressources numériques cq-dam-asset-synchronization-service

Le service AssetSynchronizationService permet de synchroniser les ressources des référentiels montés (y compris LiveLink et Documentum®, entre autres). Par défaut, il effectue une vérification régulière toutes les 300 secondes (5 minutes), donc si vous n’utilisez pas de référentiels montés, vous pouvez désactiver ce service.

Pour désactiver le service, configurez le service OSGi CQ DAM Asset Synchronization Service pour définir la période de synchronisation (scheduler.period) à (un minimum d’)un an (en secondes).

Instances multiples de gestion des ressources numériques multiple-dam-instances

Le déploiement de plusieurs instances de gestion des ressources numériques peut améliorer les performances si, par exemple :

Autres points à prendre en compte :

Bonnes pratiques pour l’assurance qualité best-practices-for-quality-assurance

Les performances sont primordiales pour votre environnement de publication. Par conséquent, vous devez soigneusement planifier et analyser les tests de performances que vous effectuez pour l’environnement de publication lors de l’implémentation de votre projet.

Cette section vise à donner un aperçu normalisé des problèmes liés à la définition d’un concept de test spécifique pour les tests de performances dans votre environnement de publication. Cette information s’adresse principalement aux ingénieures et ingénieurs en assurance qualité, aux cheffes et chefs de projet et aux administrateurs et administratrices système.

Le contenu suivant présente une approche normalisée des tests de performances pour une application AEM sur l’environnement de publication. Ce test de performances implique les cinq phases suivantes :

Le contrôle est un processus supplémentaire et global, nécessaire mais non limité aux tests.

Vérification des connaissances verification-of-knowledge

Une première étape consiste à documenter les informations de base que vous devez connaître avant de pouvoir démarrer les tests :

Architecture de test test-architecture

Documentez l’architecture de l’environnement de test utilisé pour vos tests de performances.

Vous avez besoin d’une reproduction de votre environnement de publication de production prévu, avec Dispatcher et la répartition de charge.

Carte de l’application application-map

Obtenez un aperçu clair à partir duquel vous pouvez créer une carte de l’ensemble de l’application (vous disposez peut-être déjà de cette carte grâce aux tests dans l’environnement de création).

Un diagramme représentant les éléments internes de l’application peut donner un aperçu des exigences de test. Avec le codage par couleur, il peut également servir de base pour la création de rapports.

Définition de la portée scope-definition

Une application comporte généralement une sélection de cas d’utilisation. Certains cas d’utilisation sont importants, d’autres moins.

Pour cibler la portée des tests de performances en mode de publication, Adobe vous recommande de définir les éléments suivants :

Le nombre de cas d’utilisation dépend de vous, mais il doit être limité à un nombre facilement gérable (par exemple, entre 5 et 10).

Une fois les cas d’utilisation clés sélectionnés, les indicateurs de performance clés et les outils utilisés pour les mesurer peuvent être définis pour chaque cas. Voici quelques exemples de KPI courants :

Méthodologies de test test-methodologies

Ce concept comporte quatre scénarios utilisés pour définir et tester les objectifs de performances :

Sur la base des principes suivants.

Points d’arrêt des composants component-breakpoints

Transactions transactions

Définir les objectifs de performances defining-the-performance-goals

Une fois la portée et les KPI associés définis, les objectifs de performances spécifiques sont définis. Ce processus implique la conception de scénarios de test, ainsi que de valeurs cibles.

Testez les performances dans des conditions moyennes et de pointe. En outre, vous avez besoin de tests de scénario en ligne pour vous assurer que vous pourrez faire face à un intérêt accru pour votre site web lorsqu’il sera disponible.

Toute expérience ou statistique que vous avez peut-être collectée sur un site web existant peut également se révéler utile pour déterminer les objectifs futurs. Par exemple, le trafic le plus élevé provenant de votre site web actif.

Tests sur des composants uniques single-component-tests

Les composants essentiels doivent être testés dans des conditions moyennes et de pointe.

Dans les deux cas, vous pouvez définir le nombre de transactions attendu par seconde lorsqu’un nombre prédéfini d’utilisateurs et d’utilisatrices utilisent le système.

Tests combinés des composants combined-component-tests

Le test combiné des composants permet de mieux visualiser le comportement des applications. Là encore, les conditions moyennes et de pointe doivent être testées.

Tests en ligne going-live-tests

Au cours des premiers jours suivant la mise en ligne de votre site web, attendez-vous à un niveau élevé d’intérêt. Ce scénario est même supérieur aux valeurs de pointe que vous testez. Adobe vous recommande de tester les scénarios en ligne pour vous assurer que le système peut faire face à cette situation.

Tests de scénario d’erreur error-scenario-tests

Testez les scénarios d’erreur pour vous assurer que le système réagit correctement et conformément aux attentes. Non seulement en termes de traitement de l’erreur elle-même, mais aussi de répercussions sur les performances. Par exemple :

Lors de la conception de ces tests, il faut se rappeler que tous les scénarios ne se produisent pas régulièrement. Cependant, leur impact sur l’ensemble du système est important.

Tests d’endurance endurance-tests

Certains problèmes ne sont rencontrés qu’après une exécution du système pendant une période continue, que l’on compte en heures ou en jours. Un test d’endurance est utilisé pour tester une charge moyenne constante sur une période donnée. Toute dégradation des performances peut être ensuite analysée.

Optimisation optimization

Lors des étapes suivantes de la mise en œuvre, optimisez l’application afin d’atteindre et d’optimiser les objectifs de performances.

Toutes les optimisations effectuées doivent être testées pour s’assurer :

Une sélection d’outils est disponible pour vous aider dans la génération de la charge, la surveillance des performances et l’analyse des résultats. Voici quelques-uns de ces outils :

Après l’optimisation, testez à nouveau pour confirmer l’impact.

Création de rapports reporting

Les rapports en cours informent tout le monde du statut. Comme mentionné précédemment avec le codage par couleur, la carte d’architecture peut être utilisée pour ce statut.

Une fois tous les tests terminés, faites un rapport :

Optimisation des performances lors de l’utilisation du Dispatcher optimizing-performance-when-using-the-dispatcher

Le Dispatcher est l’outil de mise en cache et/ou d’équilibrage de charge d’Adobe. Lorsque vous utilisez le Dispatcher, pensez à optimiser votre site web en termes de performances du cache.

Le Dispatcher propose un certain nombre de mécanismes intégrés que vous pouvez utiliser pour optimiser les performances à condition que votre site web en tire parti. Dans cette section, vous apprendrez comment concevoir votre site web afin de tirer le meilleur parti des avantages de la mise en cache.

Calcul du ratio de cache du Dispatcher calculating-the-dispatcher-cache-ratio

La formule du ratio de cache estime le pourcentage de requêtes traitées par le cache sur le nombre total de requêtes entrant dans le système. Pour calculer ce ratio, vous avez besoin des éléments suivants :

Formule de calcul du ratio :

Par exemple, si le nombre total de requêtes est de 129 491 et que le nombre de requêtes servies par l’instance de publication est de 58 959, le ratio de cache est : (129 491 - 58 959)/129 491= 54,5 %.

Si vous ne disposez pas d’une association un-à-un éditeur/dispatcher, ajoutez les requêtes de tous les dispatchers et éditeurs ensemble pour obtenir une mesure précise. Voir aussi Déploiements recommandés.

Utilisation d’un codage cohérent de page using-consistent-page-encoding

Avec le Dispatcher version 4.1.11, vous pouvez mettre en cache les en-têtes de réponse. Si vous ne mettez pas en cache les en-têtes de réponse sur le Dispatcher, des problèmes peuvent survenir quand vous stockez des informations de codage de page dans l’en-tête. Dans ce cas, lorsque le Dispatcher diffuse une page du cache, le codage par défaut du serveur web est utilisé pour la page. Deux méthodes permettent d’éviter ce problème :

        <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

Contournement des paramètres d’URL avoid-url-parameters

Si possible, évitez les paramètres d’URL des pages que vous souhaitez mettre en cache. Par exemple, si vous disposez d’une galerie d’images, l’URL suivante n’est jamais mise en cache (sauf si le Dispatcher est configuré en conséquence) :

www.myCompany.com/pictures/gallery.html?event=christmas&page=1

Vous pouvez toutefois placer ces paramètres dans l’URL de page, comme suit :

www.myCompany.com/pictures/gallery.christmas.1.html

Personnalisation par URL customize-by-url

Si vous autorisez les utilisateurs et utilisatrices à modifier la taille de la police (ou toute autre personnalisation de la disposition), assurez-vous que les différentes personnalisations sont reflétées dans l’URL.

Par exemple, les cookies ne sont pas mis en cache. Par conséquent, si vous stockez la taille de police dans un cookie (ou un mécanisme similaire), celle-ci ne sera pas conservée pour la page mise en cache. Par conséquent, le Dispatcher renvoie aléatoirement des documents de n’importe quelle taille de police.

L’inclusion de la taille de police dans l’URL en tant que sélecteur évite ce problème :

www.myCompany.com/news/main.large.html

Invalidation de fichiers image utilisés comme titres invalidating-image-files-used-as-titles

Si vous effectuez le rendu des titres de page, ou d’un autre texte, sous forme d’images, il est recommandé de stocker les fichiers afin qu’ils soient supprimés lors d’une mise à jour du contenu sur la page :

Par exemple, vous pouvez stocker le titre de la page myPage.html dans le file myPage.title.gif. Ce fichier est automatiquement supprimé si la page est mise à jour. Toute modification du titre de la page est donc automatiquement répercutée dans le cache.

Invalidation des fichiers image utilisés pour la navigation invalidating-image-files-used-for-navigation

Si vous utilisez des images pour les entrées de navigation, la méthode est fondamentalement la même qu’avec les titres mais seulement un peu plus complexe. Stockez toutes les images de navigation avec les pages cibles. Si vous utilisez deux images pour « normale » et « active », vous pouvez utiliser les scripts suivants :

Il est important que vous créiez ces images avec le même nom d’utilisateur que la page, afin de vous assurer qu’une mise à jour du contenu supprime ces images et la page.

Pour les pages qui ne sont pas modifiées, les images restent dans le cache, bien que les pages elles-mêmes soient automatiquement invalidées.

Personnalisation personalization

Il est recommandé de limiter la personnalisation à l’endroit nécessaire. En voici la raison :

Si vous personnalisez chaque page en plaçant le nom de l’utilisateur ou de l’utilisatrice dans la barre de titre (par exemple), cela a un impact sur les performances.

En ce qui concerne le mélange de contenu public et restreint sur une page, envisagez une stratégie qui utilise les inclusions côté serveur dans le Dispatcher, ou les inclusions côté client au moyen de l’option Ajax dans le navigateur.

Connexions persistantes sticky-connections

Les connexions persistantes garantissent que les documents d’un utilisateur ou d’une utilisatrice sont tous composés sur le même serveur. Si un utilisateur ou une utilisatrice quitte ce dossier et y revient ultérieurement, la connexion reste établie. Pour contenir tous les documents qui nécessitent des connexions persistantes sur le site web, définissez un dossier. Essayez de ne pas y avoir d’autres documents. Ce scénario a un impact sur l’équilibrage de la charge si vous utilisez des pages personnalisées et des données de session.

Types MIME mime-types

Un navigateur peut déterminer le type d’un fichier de deux façons différentes :

Pour la plupart des fichiers, le type MIME est implicite dans l’extension de fichier. C’est-à-dire :

Si le nom de fichier ne comporte aucune extension, il s’affiche sous forme de texte brut.

Avec le Dispatcher version 4.1.11, vous pouvez mettre en cache les en-têtes de réponse. Si vous ne mettez pas en cache les en-têtes de réponse sur le Dispatcher, le type MIME fait partie de l’en-tête HTTP. À cet égard, si votre application AEM renvoie des fichiers qui n’ont pas d’extension reconnue, mais utilisent le type MIME à la place, ces fichiers risquent d’être affichés de manière erronée.

Pour vous assurer que les fichiers sont correctement mis en cache, suivez ces instructions :

Performances des sauvegardes backup-performance

Cette section présente une série de points de référence utilisés pour évaluer les performances des sauvegardes AEM et les effets de l’activité de sauvegarde sur les performances des applications. Les sauvegardes AEM présentent une charge importante sur le système pendant leur exécution. Adobe mesure cet impact, ainsi que les effets des paramètres de délai de sauvegarde qui tentent de moduler ces conséquences. L’objectif est de fournir des données de référence sur les performances attendues des sauvegardes dans des configurations et des quantités de données de production réalistes, tout en fournissant des conseils sur la manière d’estimer les temps de sauvegarde pour les systèmes planifiés.

Environnement de référence reference-environment

Système physique physical-system

Les résultats signalés dans ce document ont été obtenus à partir de références exécutées dans un environnement de référence avec la configuration ci-après. Cette configuration se rapproche d’un environnement de production type d’un centre de données :

Le sous-système de disque sur ce serveur est rapide et représentatif d’une configuration RAID haute performance qui peut être utilisée dans un serveur de production. Les performances de sauvegarde peuvent être sensibles aux performances du disque et les résultats de cet environnement reflètent les performances sur une configuration RAID rapide. L’image VMWare est configurée pour avoir un seul gros volume de disque qui réside physiquement dans le stockage du disque local, sur la baie RAID.

La configuration AEM place le référentiel et le magasin de données sur le même volume logique, avec tous les autres logiciels du système d’exploitation et d’AEM. Le répertoire cible des sauvegardes se trouve également sur ce système de fichiers logique.

Volumes de données data-volumes

Le tableau ci-après illustre la taille des volumes de données utilisés dans les repères de sauvegarde. Le contenu de base initial est d’abord installé, puis des quantités de données connues supplémentaires sont ajoutées pour augmenter la taille du contenu sauvegardé. Des sauvegardes sont créées à des incréments spécifiques afin de représenter une augmentation importante du contenu, ainsi que du volume qui peut être produit en un jour. La distribution du contenu (pages, images, balises) repose essentiellement sur une composition réaliste des ressources de production. Les pages, images et balises sont limitées à 800 pages enfants au maximum. Chaque page comprend des composants titre, Flash, texte/image, vidéo, diaporama, formulaire, tableau, cloud et carrousel. Les images sont chargées à partir d’un pool de 400 fichiers uniques de 37 Ko à 594 Ko.

L’essai comparatif de sauvegarde est réitéré avec des jeux de contenu supplémentaires ajoutés à chaque itération.

Scénarios de référence benchmark-scenarios

Les références de sauvegarde couvrent deux scénarios principaux : des sauvegardes sont effectuées lorsque le système est soumis à une charge d’application importante d’une part et lorsque le système est inactif d’autre part. Selon la recommandation générale, les sauvegardes doivent être effectuées lorsqu’AEM est aussi inactif que possible. Pourtant, il existe des situations où il est nécessaire que la sauvegarde soit exécutée quand le système est en charge.

La durée des sauvegardes et la taille des sauvegardes qui en résultent sont obtenues à partir des journaux du serveur AEM. Il est généralement recommandé de planifier des sauvegardes pendant des périodes d’interruption lorsqu’AEM est inactif, par exemple au milieu de la nuit. Ce scénario illustre l’approche recommandée.

La charge est composée des ressources suivantes : les pages créées, les pages supprimées, les parcours et les requêtes. Les parcours et requêtes de page ont le plus gros impact sur la charge. L’ajout et la suppression d’un nombre trop élevé de pages augmentent continuellement la taille de l’espace de travail et empêchent les sauvegardes de se terminer. Le script utilise une charge composée de 75 % de parcours de page, 24 % de requêtes et 1 % de pages créées (niveau unique sans sous-pages imbriquées). La moyenne maximale de transactions par seconde sur un système inactif est atteinte avec quatre threads simultanés. Cette approche est utilisée lors des tests de sauvegarde en situation de charge.

L’impact de la charge sur les performances de sauvegarde peut être calculé par la différence de performance avec et sans la charge de l’application. Pour déterminer l’impact de la sauvegarde sur le débit de l’application, comparez le débit du scénario en transactions par heure avec et sans sauvegarde simultanée en cours, tout en utilisant différents paramètres de « délai de sauvegarde ».

Résumé des résultats summary-of-results

Durée et débit de sauvegarde backup-time-and-throughput

Ces références montrent que les temps de sauvegarde sont le produit du type de sauvegarde et de la quantité de données. Le graphique suivant montre le temps nécessaire à la sauvegarde dans la configuration de sauvegarde par défaut, en fonction du nombre total de pages.

Les durées des sauvegardes sur une instance inactive sont relativement constantes, avec une moyenne de 0,608 Mo/s, qu’il s’agisse de sauvegardes complètes ou incrémentielles (voir le tableau ci-dessous). La durée de sauvegarde est simplement fonction de la quantité de données sauvegardées. Le temps nécessaire pour effectuer une sauvegarde complète augmente nettement avec le nombre total de pages. La durée nécessaire à la sauvegarde incrémentielle augmente également avec le nombre total de pages, mais à un taux beaucoup plus faible. La durée d’une sauvegarde incrémentielle est beaucoup plus courte, car il y a moins de données à sauvegarder.

La taille de la sauvegarde produite est le principal facteur déterminant du temps nécessaire pour effectuer une sauvegarde. Le graphique ci-après montre l’évolution de la durée en fonction de la taille de la sauvegarde finale.

Ce graphique montre que les sauvegardes incrémentielles et complètes suivent une équation simple, où la taille influe sur la durée et inversement, qu’Adobe peut mesurer en tant que débit. Les durées de sauvegarde sur une instance inactive sont assez constantes, avec une moyenne de 0,61 Mo par seconde, qu’il s’agisse de sauvegardes complètes ou incrémentielles dans l’environnement de référence.

Délai de sauvegarde backup-delay

Le paramètre de délai de sauvegarde permet de limiter l’impact des sauvegardes sur les charges de travail de production. Le paramètre spécifie un temps d’attente en millisecondes, qui est intercalé entre chaque fichier dans l’opération de sauvegarde. L’impact global dépend notamment de la taille des fichiers concernés. La mesure des performances de sauvegarde en Mo/s offre un moyen simple de comparer les effets du délai sur la sauvegarde.

À titre de comparaison, voici le débit obtenu à l’aide d’une sauvegarde du système de fichiers (« tar ») pour sauvegarder les mêmes fichiers de référentiel. Les performances du tar sont comparables, mais légèrement supérieures à la sauvegarde avec un délai défini sur zéro. La spécification d’un paramètre de délai, aussi faible soit-il, réduit le débit de sauvegarde à peau de chagrin. Le délai par défaut de 10 millisecondes confirme cette tendance. Si des sauvegardes peuvent être planifiées lorsque l’application est peu sollicitée ou est inactive, réduisez le délai sous la valeur par défaut pour permettre une sauvegarde plus rapide.

L’impact réel du débit de l’application lors d’une sauvegarde en cours dépend de la configuration de l’application et de l’infrastructure. Avant toute définition de valeur de délai, une analyse empirique de l’application s’impose. Le cas échéant, choisissez une valeur aussi faible que possible, de sorte que les sauvegardes puissent être rapidement effectuées. Comme le choix de la valeur de délai influe peu ou prou sur le débit de l’application, indiquez une valeur de délai qui permet de réduire au maximum les durées de sauvegarde. L’impact global des sauvegardes est ainsi atténué autant que possible. Une sauvegarde qui se termine en huit heures, avec en contrepartie une réduction du débit de 20 %, risque d’avoir un impact global plus important qu’une sauvegarde de deux heures avec une réduction du débit de 30 %.

Références references