Date de publication: le lundi 6 août 2007 à 16h29
Dernière modification: par Pascal BOYER le dimanche 26 septembre 2010 à 21h21
Testing should not be postponed until just before the project goes live. Instead, it should be an ongoing effort that validates each step of development and implementation. This section describes some testing techniques that will help you analyze and optimize performance.
La phase de tests ne doit pas être planifiée juste avant la mise en production du site. Bien au contraire, les tests doivent constituer un effort constant pour valider chaque étape du développement du projet. Cette section décrit quelques techniques de test qui vous aideront à analyser et optimiser les performances.
Using the debug output / Utliser la sortie de debugage
The debug output provided by eZ Publish is extremely useful. It is enabled in the site.ini configuration file ([DebugSettings], DebugOutput=enabled). Debug output generates verbose notices, warnings and errors, and also provides a profiling tool that shows how page generation time is divided among the page construction phases. While the profiler was not specifically designed as a performance or load testing tool, it will give you the ability to immediately identify bottlenecks and major issues during unit testing and thus to correct many potential problems.
Le système de "sortie de débugage" (c'est à dire d'affichage de messages de débugage) fournit par eZ Publish est extrêmement utile. Il est activé par le paramètre
DebugOutput
(positionné à enabled) de la section [DebugSettings] du fichier de configuration site.ini. La sortie de débugage, qui affiche des messages verbeux, des avertissements et des erreurs, fournit également un outil ...(???) permettant de voir comment le temps de génération d'une page est divisé entre les différentes phases de construction. Bien que cet outil (???) n'ait pas été spécialement conçu pour être un outil de test de performance ou de charge, il vous permettra d'identifier immédiatement, pendant les tests, les goulots d'étranglement et les problèmes majeurs qui surviennent et donc de corriger nombre de problèmes potentiels.
For example, after enabling caching, you can use the profiler to ensure that SQL queries are not executed when cache blocks are enabled. You should see three SQL queries on a standard page load when ViewCaching is enabled. If you see more, for instance 20 or 30, something is wrong.
Par exemple, après avoir activé la mise en cache vous pouvez utiliser le profiler (???) pour vous assurer que les requêtes MySQL ne sont pas exécutées lorsque les blocs de cache sont activés. Si la mise en cache de visualisation est activée, vous ne devez voir que trois requêtes MySQL lors du chargement d'une page standard. Si vous en voyez plus, 20 ou 30 par exemple, alors quelque chose ne va pas.
It's quite common to ignore non-critical messages in the debug output (such as compiler errors, uninitialized variables, etc). However, even if the errors have (or seem to have) no impact, they should be fixed as soon as possible. Errors are indicators of system instability or misconfiguration, and may have side effects, including performance impacts. For the sake of project maintenance, the debug output should show a clean system.
Il est courant d'ignorer, dans les sorties de débugage, les messages non critiques (tels que les erreurs de compilation, les variables non initialisées, etc...). Cependant, même si les erreurs n'ont pas d'impact (ou ne semblent pas en avoir), il est préférable qu'elles soient corrigées aussi vite que possible. Les erreurs sont des indicateurs d'instabilités du système ou de mauvaises configurations et peuvent donc avoir des effets de bord et même impacter les performances. Afin de rendre la maintenance du projet plus facile, les sorties de débugage doivent montrer un système propre.
Error log / Journaux d'erreur
Another useful source of information is the error log in var/log/error.log . It can, among other things, show you when a file that doesn't exist is being requested by a browser (for example a JavaScript file you have removed but forgot to remove from the template code or the website icon). When this happens, a request is sent to eZ Publish with a "module not found" error, and every page load actually starts two instances of eZ Publish, which uses a lot of unnecessary server resources.
Une autre source intéressante d'informations est le journal d'erreur, c'est à dire le fichier var/log/error.log. Ce fichier peut, entre autres, vous indiquer si un fichier requis est manquant (par exemple un fichier javascript que vous auriez supprimé de l'arborescence mais pas du template qui l'appelle, ou l'icône du site, etc...). Lorsque cela arrive, une requête, utilisant inutilement beaucoup de ressources serveur, est envoyée à eZ Publish avec l'erreur "module non trouvé" et chaque chargement de page démarre deux instances de eZ Publish.
Load testing / Tester la charge
Load testing must be run periodically during project development and implementation. To start load tests just before launching a project is extremely risky and unprofessional. Unfortunately, this is a common mistake because developers, testers and project managers usually focus on visible tasks (such as page layout, features, etc) and not on transparent infrastructure issues (such as performance).
Les tests de charge doivent être lancés périodiquement au cours du développement du projet. Démarrer les tests de charge juste avant de mettre le projet en ligne est extrêmement risqué et peu professionnel. Malheureusement, cette erreur est fréquente car les développeurs, les testeurs et les responsables de projets se concentrent habituellement sur les tâches visibles (comme la mise en page, les fonctionnalités, etc...) et non sur les problèmes cachés (telles que les performances).
Several tools can help you in the load testing process, such as Apache Benchmark (provided with the Apache HTTP server), Siege or Jmeter. They show you how well your project scales as the number of visitors increases. However, be aware that these tools can severely impact your server if not used properly, since they can start hundreds of simultaneous requests to your website.
Plusieurs outils peuvent vous aider dans le processus de test de charge, par exemple
Apache Benchmark
(qui est fournit par le serveur HTTP Apache), mais aussi
Siege
ou
Jmeter
. Ces outils vous montrent comment se comportera votre projet au fur et à mesure que le nombre de visiteurs augmentera. Cependant, sachez que ces outils peuvent sévèrement impacter votre serveur s'ils ne sont pas correctement utilisés. En effet, ils peuvent envoyer à votre serveur des centaines de requêtes simultanées.
There are two aspects to benchmarking project performance. The first is benchmarking from within the local network or from the server itself. These benchmarks show HTTP server response time without any bandwidth variables. Second, benchmarking your platform's network availability in a "live" environment, where bandwidth varies, provides a view of your system's performance from your users' perspective.
Il y a deux aspects à prendre en compte lorsque l'on effectue des tests d'évaluation de performances. Le premier consiste à évaluer les performances depuis le réseau local ou depuis le serveur lui-même. Ces tests évaluent le temps de réponse du serveur HTTP sans tenir de paramètres liés à la bande-passante. Le second, qui consiste à évaluer les performances réseau de votre plate-forme dans un environnement réel (c'est à dire de production) où la bande-passante varie, donne un aperçu des performances de votre système vu du côté utilisateur.
Commentaires