Bonnes pratiques pour les tests de performance best-practices-for-performance-testing

Présentation introduction

Les tests de performance constituent une partie importante de tout déploiement d’AEM. Selon les besoins de la clientèle, les tests de performance peuvent être effectués sur les instances de publication, de création ou les deux.

Cette documentation présente les stratégies et méthodes globales d’exécution des tests de performance ainsi que certains des outils mis à disposition par Adobe pour faciliter le processus. Enfin, lisez une analyse des outils disponibles dans AEM 6 pour faciliter l’optimisation des performances, tant du point de vue de l’analyse du code que de la configuration du système.

Simuler la réalité simulating-reality

Lors des tests de performance, veillez à imiter un environnement de production du mieux possible. Bien qu’une telle tâche puisse souvent être difficile, il est impératif d’assurer l’exactitude de ces tests. Lorsque vous concevez des tests de performance, il est important de prendre en compte les points suivants :

De nombreuses mesures de performances dans AEM, telles que le temps de réponse des requêtes, peuvent être affectées par la taille du contenu sur le système. Il est important de s’assurer que l’environnement de test dispose d’une copie aussi proche que possible des données de production.

La version d’AEM et les correctifs déployés en production doivent être identiques dans l’environnement de test. Il est également important de tester la version du code déployé en production.

Les tests n’ont aucun sens sans environnement qui ressemble le plus possible à celui de la production. Idéalement, les spécifications matérielles, les interfaces réseau, les équilibreurs de charge et le réseau CDN doivent être identiques à la production dans l’environnement de test.

De nombreux problèmes de performances ne sont pas visibles tant que le système n’est pas soumis à une charge importante. De bons tests de performance doivent simuler la charge que les systèmes de production subissent à leur maximum.

Définir des objectifs setting-goals

Avant de commencer les tests de performance, il est nécessaire de définir des exigences non fonctionnelles pour spécifier les temps de chargement et de réponse. Si vous migrez à partir d’un système existant, assurez-vous que le temps de réponse est similaire à vos valeurs de production actuelles. Pour la charge, il est préférable d’utiliser la charge de pointe actuelle et de la doubler. Cela permet de s’assurer que le site web peut continuer à fonctionner correctement au fur et à mesure de son développement.

Outils tools

De nombreux outils de test de performance sont proposés sur le marché. Lors de l’exécution d’un outil de génération de charge, il est important de s’assurer que les ordinateurs qui effectuent les tests disposent d’une bande passante réseau suffisante. Dans le cas contraire, une fois que la machine de test a atteint les limites de sa connexion, aucune charge supplémentaire n’est générée sur l’environnement en cours de test.

Outils de test testing-tools

Outils d’optimisation optimization-tools

Surveillance

La documentation sur la surveillance des performances est une bonne ressource pour les outils et les méthodes qui peuvent être utilisés pour diagnostiquer les problèmes et identifier les zones à optimiser.

Mode Développeur de l’IU tactile

L’une des nouvelles fonctionnalités de l’interface utilisateur tactile d’AEM 6 est le mode Développeur. De la même manière que les auteurs et autrices peuvent passer du mode de modification au mode d’aperçu, les développeurs et développeuses peuvent passer en mode Développeur dans l’interface utilisateur de création. Cela vous permet d’afficher le temps de rendu de chacun des composants sur la page et d’afficher les traces de pile des erreurs. Pour plus d’informations sur le mode Développeur, reportez-vous à cette présentation Gems de CQ.

Utilisation de rlog.jar pour lire les journaux de requêtes

Pour une analyse plus complète des journaux de demandes d’un système AEM, vous pouvez utiliser rlog.jar pour rechercher et trier les fichiers request.log générés par AEM. Ce fichier jar est inclus avec une installation AEM dans le dossier /crx-quickstart/opt/helpers. Pour plus d’informations sur l’outil rlog et le journal des requêtes en général, reportez-vous à la documentation sur la surveillance et maintenance.

Outil Expliquer la requête

L’outil Expliquer la requête dans les Outils AEM d’ACS peut être utilisé pour afficher les index utilisés lors de l’exécution d’une requête. Cet outil est utile pour optimiser les requêtes à exécution lente.

Outils PageSpeed

Les outils PageSpeed de Google proposent une analyse de site pour garantir le respect des bonnes pratiques en matière de performances de page, ainsi qu’un plug-in pouvant être installé avec le Dispatcher sur une instance Apache pour des optimisations supplémentaires.
Reportez-vous au site web des outils PageSpeed.

Environnement de création author-environment

Exécution de tests performing-tests

Pour réaliser des tests de performance dans l’environnement de création, il est nécessaire de simuler l’expérience des auteurs et autrices de production. En d’autres termes, les installations de création doivent contenir tous les composants, les lots OSGi, la personnalisation de l’interface utilisateur, les index personnalisés et tous les autres ajouts que vous avez mis en place pour les instances de création de production.

De nombreuses structures d’automatisation disponibles sont conçues pour les tests de performance et de charge. Des scripts personnalisés peuvent être enregistrés dans ces outils, puis exécutés pour simuler un nombre maximal d’auteurs effectuant simultanément des activités similaires de création et d’activation de contenu. Il est recommandé d’utiliser l’outil Tough Day pour simuler des activités telles que le chargement de milliers de ressources ou l’activation d’un grand nombre de pages.

Pour les types d’environnements qui nécessitent un chargement de ressources important ou la création d’un grand nombre de pages, il est impératif d’utiliser des outils tels que Tough Day. Cela permet de s’assurer que l’environnement fonctionne efficacement sous une charge maximale. WebDAV est un outil qui ne nécessite aucun script et qui peut également servir à charger de grandes quantités de ressources.

Étapes spécifiques à MongoDB mongodb-specific-steps

Sur les systèmes disposant de serveurs principaux MongoDB, AEM fournit plusieurs MBeans JMX qui doivent être surveillés lors des tests de chargement ou de performances :

https://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D6%2Cname%3D%22Consolidated+Cache+statistics%22%2Ctype%3D%22ConsolidatedCacheStats%22

Pour le cache nommé Document-Diff, le taux d’accès doit être supérieur à .90. Si le taux d’accès se retrouve en dessous de 90 %, il est probable que vous deviez modifier la configuration DocumentNodeStoreService. La prise en charge du produit Adobe peut recommander des paramètres optimaux pour votre environnement.

https://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D16%2Cname%3D%22Oak+Repository+Statistics%22%2Ctype%3D%22RepositoryStats%22

La section ObservationQueueMaxLength indique le nombre d’événements dans la file d’attente d’observation d’Oak au cours des dernières heures, minutes, secondes et semaines. Recherchez le plus grand nombre d’événements dans la section « Par heure ». Comparez ce nombre au paramètre oak.observation.queue-length. Si le nombre le plus élevé affiché pour la file d’attente d’observation dépasse la valeur du paramètre queue-length :

Le paramètre par défaut est 10 000, mais la plupart des déploiements doivent l’augmenter jusqu’à 20 000 ou 50 000.

Environnement de publication publish-environment

Exécuter des tests performing-tests-1

La partie la plus importante d’un déploiement qui doit être soumise à des tests de chargement est l’environnement de publication ou du Dispatcher de l’utilisateur final.

Il est possible d’utiliser des outils de test automatisés tiers pour tester les performances du site web. Ces outils vous permettent d’enregistrer les étapes que les utilisateurs et utilisatrices suivent sur le site et d’exécuter plusieurs de ces sessions en même temps pour simuler la charge type d’un site web de production.

La plupart des sites web de production disposent d’optimisations telles que la mise en cache du Dispatcher et la mise en place d’un réseau de diffusion de contenu. Lors du test, assurez-vous que ces optimisations sont également disponibles pour l’environnement de test. Outre la surveillance des temps de réponse pour les utilisateurs et utilisatrices finaux, surveillez les mesures du système sur les serveurs de publication et les dispatchers pour vous assurer que le système n’est pas limité par les ressources matérielles.

Sur un système qui ne nécessite pas un niveau élevé de personnalisation, le Dispatcher doit mettre en cache la plupart des requêtes. Par conséquent, la charge sur l’instance de publication doit rester relativement nulle. Si un niveau élevé de personnalisation est requis, il est recommandé d’utiliser des technologies telles que les requêtes iFrames ou AJAX pour le contenu personnalisé afin de permettre une mise en cache maximale du Dispatcher.

Pour les tests de base, il est possible d’utiliser Apache Bench pour mesurer les temps de réponse du serveur web et créer la charge pour mesurer des éléments comme les fuites de mémoire. Voir l’exemple dans la documentation sur la surveillance.

Résoudre les problèmes de performances troubleshooting-performance-issues

Après l’exécution des tests de performance sur l’instance de création, tous les problèmes doivent être étudiés, diagnostiqués et résolus. Vous pouvez utiliser plusieurs outils et techniques pour effectuer des analyses et résoudre des problèmes :

Une fois les zones problématiques identifiées, le code de l’application peut être inspecté pour optimiser les performances. Toutes les fonctionnalités AEM prêtes à l’emploi qui ne fonctionnent pas correctement peuvent être traitées par l’assistance d’Adobe.