Les premiers pas
Les tests de charge peuvent s'adresser à tout type de projet, mais il vise d'abord des sites Web avec des centaines d'utilisateurs ou plus.
Les tests de charge sont l'un des tests les plus négligés en informatique. Souvent, il y a un test de charge uniquement avant le lancement d'un nouveau site ou il n'y pas de test de charge du tout. Résultat, le nouveau site ayant été lancés à planter dans les premières heures parce que les responsables du site n'avaient pas prévu que le site serait aussi populaire. Pourtant, la situation aurait pu être évité si on aurait effectuer un simple de test de charge.
Les tests de charge, une fois le site lancé, devrait également avoir lieu suite à l'implémentation de nouvelle partie majeur et de certaines mise à jour. Souvent, l'ajout de nouvelle composante sont basés sur des projets ou modules open source dont la fiabilité et la performance ne sont tous simplement pas mentionné dans la documentation des sites opensource. Résultat, vous ajoutez une fonctionnalité fonctionnant bien en local ou sur un serveur de développement, mais dans un contexte réel, la nouvelle composante provoque un ralentissement important de la vitesse du site et au final vous avez besoins de deux fois plus de serveur !
Les tests de charge ne sont pas un mécanisme complexe difficile à produire. En faite, si vous êtes capable de faire une répétition d'une même opération et dans vérifier le résultat, vous avez un test de charge. Normalement, cependant, pour facilité la compréhension, on créera un plan de test pour catégorisé les tests effectués, mais ceux-ci sont uniquement un regroupement de test de même catégorie qui eut sont en faite des répétitions d'un même tests.
Il est important de noter que lorsqu'on augmente la quantité de test de charge, la réponse d'erreur retourner par le serveur peuvent variés considérablement, le changement de type d'erreur peut souvent révéler différents types de faiblesse dans les serveurs n'ayant rien à voir en faite, avec le code d'un développeur mais serait plutôt dû à des mauvaises configurations de serveurs.
Un processus de test de charge se divise généralement en 5 étapes : Définir les cibles, configurer un environnement de test de charge, créer des scénarios de test, exécuter des tests et analyser le résultat.
Le serveur cible ne devrait pas être l'environnement de production, mais plutôt l'environnement précédent la production, soit généralement un environnement de staging. Si vous effectuez des tests de charge directement en production, vous allez également impacter vos clients, ce qui n'est certainement pas une bonne idée. N'oubliez pas, que vous voulez prévenir le fait que le client n'aurait pas de mauvaises expériences et non pas de décourager le client à venir sur votre site !
La configuration d'un environnement de test de charge demandera la collaboration d'un administrateur système avec le responsable du test de charge, lequel vérifiera qu'il y a le moins d'interférence possibles entre le serveur et le test de charge effectué (il vérifiera les pare feu, base de données et même il vérifiera même l'architecture réseau) afin que l'opération soit le plus directe possible.
Pour avoir un test de charge avec des données valides, il est important d'effectuer des tests de charge dans un environnement avec le moins d'intervenant possible. Ainsi, il est important de s'assurer qu'il faut par exemple éviter de passer par un VPN si le site réel ne passe pas par un VPN, car le test de charge pourrait démontrer que le site ne fournit pas ou n'est pas assez solide quand on fait, le problème viendrait du fait que le VPN ne supporte pas une pleine capacité de transmission comme un réseau Internet. DE plus, il est préférable de faire les tests en réseau interne plutôt qu'en réseau externe, car si vous appeler de l'extérieur et que votre réseau est protégé contre les DoS (Denial-of-Service), les résultats sera encore faussé à cause qu'il n'accepte pas assez d'appel en provenance d'une même source et non pas à cause que le serveur ne répond plus.
Une fois les résultats obtenu, on obtiendra un réponse très importante, est-ce que le nombre de serveurs est suffisant ou il faut en rajouter plus. Sinon, si cette option n'est pas envisageable, le code proposé par les développeurs a-t-il été bien optimisé. Est-ce qu'il n'y aurait pas moyen de rendre le code plus efficace. Pour répondre à cette question, il faudra nécessairement avoir un historique des tests de charge et comparer avec les résultats de test de charge avant l'ajout d'un nouveau développement et après l'ajout du nouveau développement.