Comment effectuez-vous les tests de charge et la planification de la capacité des sites Web?
Il s'agit d'une question canonique sur la planification de la capacité des sites Web.
En relation:
Quels sont les outils et méthodes recommandés pour la planification de la capacité des sites Web et des applications Web?
N'hésitez pas à décrire différents outils et techniques pour différents serveurs Web, frameworks, etc., ainsi que les meilleures pratiques qui s'appliquent aux serveurs Web en général.
La réponse courte est: personne ne peut répondre à cette question sauf vous.
La réponse longue est que l'analyse comparative de votre charge de travail spécifique est quelque chose que vous devez entreprendre vous-même, car c'est un peu comme demander "Quelle est la longueur d'un morceau de ficelle?".
Un simple site Web statique d'une page peut être hébergé sur un Pentium Pro 150 et diffuser des milliers d'impressions chaque jour.
L'approche de base que vous devez adopter pour répondre à cette question consiste à l'essayer et voir ce qui se passe. Il existe de nombreux outils que vous pouvez utiliser pour mettre artificiellement votre système sous pression pour voir où il se boucle.
Un bref aperçu de ceci est:
- Mettez votre scénario en place
- Ajouter une surveillance
- Ajouter du trafic
- Évaluez les résultats
- Correction en fonction des résultats
- Rincer, répéter jusqu'à ce qu'il soit raisonnablement heureux
Mettez votre scénario en place
Fondamentalement, pour tester une certaine charge, vous avez besoin de quelque chose contre lequel tester. Configurez un environnement pour tester. Cela devrait être une estimation assez proche de votre matériel de production si possible, sinon vous devrez extrapoler vos données.
Configurez vos serveurs, comptes, sites Web, bande passante, etc. Même si vous le faites sur des machines virtuelles, c'est OK tant que vous êtes prêt à faire évoluer vos résultats.
Donc, je vais configurer une machine virtuelle de moyenne puissance (deux cœurs, 512 Mo de RAM, 4 Go de disque dur) et installer mon équilibreur de charge préféré, haproxy à l'intérieur - Red Hat Linux sur la machine virtuelle.
Je vais également avoir deux serveurs Web derrière l'équilibreur de charge que je vais utiliser pour tester la résistance de l'équilibreur de charge. Ces deux serveurs Web sont configurés de manière identique à mes systèmes en direct.
Ajouter une surveillance
Vous aurez besoin de quelques mesures pour surveiller, donc je vais mesurer le nombre de demandes qui parviennent à mes serveurs Web et le nombre de demandes que je peux parcourir par seconde avant que les utilisateurs commencent à obtenir un temps de réponse de plus de deux secondes.
Je vais également surveiller l'utilisation de la RAM, du processeur et du disque sur l'instance haproxy pour m'assurer que l'équilibreur de charge peut gérer les connexions.
La façon de procéder dépend beaucoup de vos plateformes et sort du cadre de cette réponse. Vous devrez peut-être consulter les fichiers journaux du serveur Web, démarrer les compteurs de performances ou vous fier à la capacité de génération de rapports de votre outil de test de résistance.
Quelques choses que vous souhaitez toujours surveiller:
- L'utilisation du processeur
- Utilisation de la RAM
- Utilisation du disque
- Latence du disque
- Utilisation du réseau
Vous pouvez également choisir de regarder les blocages SQL, les temps de recherche, etc. en fonction de ce que vous testez spécifiquement.
Ajouter du trafic
C'est là que les choses s'amusent. Vous devez maintenant simuler une charge de test. Il y a beaucoup d'outils qui peuvent le faire, avec des options configurables:
- JMeter (Web, LDAP)
- Apache Benchmark (Web)
- Grinder (Web)
- httperf (Web)
- WCAT (Web)
- Test de charge de Visual Studio (Web)
- SQLIO (SQL Server)
Choisissez un nombre, n'importe quel nombre. Disons que vous allez voir comment le système réagit avec 10 000 accès par minute. Peu importe le nombre que vous choisissez, car vous allez répéter cette étape plusieurs fois, en ajustant ce nombre vers le haut ou vers le bas pour voir comment le système répond.
Idéalement, vous devez répartir ces 10 000 demandes sur plusieurs clients/nœuds de test de charge afin qu'un seul client ne devienne pas un goulot d'étranglement des demandes. Par exemple, JMeter's Remote Testing fournit une interface centrale à partir de laquelle lancer plusieurs clients à partir d'une machine Jmeter de contrôle.
Appuyez sur le bouton magique Aller et regardez vos serveurs Web fondre et planter.
Évaluez les résultats
Donc, maintenant, vous devez revenir à vos mesures que vous avez collectées à l'étape 2. Vous voyez qu'avec 10 000 connexions simultanées, votre boîte haproxy brise à peine, mais le temps de réponse avec deux serveurs Web est une touche plus de cinq secondes. Ce n'est pas cool - rappelez-vous, votre temps de réponse vise deux secondes. Nous devons donc apporter quelques modifications.
Remédier
Maintenant, vous devez accélérer votre site Web de plus de deux fois. Donc, vous savez que vous devez soit évoluer, soit évoluer.
Pour évoluer, obtenez de plus grands serveurs Web, plus de RAM, des disques plus rapides.
Pour évoluer, obtenez plus de serveurs.
Utilisez vos mesures de l'étape 2 et des tests pour prendre cette décision. Par exemple, si vous avez vu que la latence du disque était massive lors des tests, vous savez que vous devez évoluer et obtenir des disques durs plus rapides.
Si vous avez vu que le processeur était à 100% pendant le test, vous devrez peut-être évoluer pour ajouter des serveurs Web supplémentaires afin de réduire la pression sur les serveurs existants.
Il n'y a pas de bonne ou de mauvaise réponse générique, il n'y a que ce qui vous convient. Essayez de passer à l'échelle, et si cela ne fonctionne pas, évoluez à la place. Ou non, c'est à vous et à certains de sortir des sentiers battus.
Disons que nous allons évoluer. J'ai donc décidé de cloner mes deux serveurs Web (ce sont des VM) et maintenant j'ai quatre serveurs Web.
Rincer, répéter
Recommencez à partir de l'étape 3. Si vous constatez que les choses ne se déroulent pas comme prévu (par exemple, nous avons doublé les serveurs Web, mais que les temps de réponse sont toujours supérieurs à deux secondes), examinez les autres goulots d'étranglement. Par exemple, vous avez doublé les serveurs Web, mais vous avez toujours un serveur de base de données merdique. Ou, vous avez cloné plus de machines virtuelles, mais comme elles se trouvent sur le même hôte physique, vous n'avez obtenu qu'un conflit plus élevé pour les ressources des serveurs.
Vous pouvez ensuite utiliser cette procédure pour tester d'autres parties du système. Au lieu de frapper l'équilibreur de charge, essayez de frapper directement le serveur Web, ou le serveur SQL à l'aide d'un outil d'analyse comparative SQL .
La planification de la capacité commence par la mesure, dans ce cas, le temps de réponse en fonction de la charge. Une fois que vous connaissez le degré de ralentissement des programmes avec la charge, qui n'est PAS une fonction linéaire, vous pouvez sélectionner un objectif de temps de réponse, puis découvrir quelles ressources il faudra pour atteindre cet objectif pour une quantité de charge donnée.
La mesure des performances se fait toujours avec temps unités, comme
- c'est ce qui intéresse les utilisateurs
- ils peuvent être augmentés et diminués
Des choses comme% CPU et IOPS sont spécifiques au système, vous ne les utilisez donc que lorsque vous avez planifié le système et l'avez mesuré en pré-production, pour agir en tant que "substitut" pour la chose qui vous intéresse, le temps.
La planification des capacités est une bête gênante. C'est autant de la science que de l'art (s'il est définitivement sombre).
Votre meilleur cas est que vous preniez des décisions bien informées et la fortune/chance vous favorise en ayant la réalité répondre à vos hypothèses. Si vos capacités ont besoin d'hypothèses correspondant à la réalité, vous ressemblez à un yogi mystique. Malheureusement, si vos hypothèses dépassent la réalité, vous semblerez avoir dépassé et dépassé. Plus malheureusement, si vos hypothèses sont inférieures à la réalité éventuelle (ou sont incorrectes), vous n'aurez pas la capacité dont vous avez besoin et devrez vous démener pour atténuer les défaillances de votre infrastructure gémissante, ce qui vous donne l'impression que vous manquez de compétences.
Pas de pression...
Malheureusement, l'art sombre de la planification de la capacité est plus que ce qui peut être raisonnablement distillé dans une seule réponse de panne de serveur; vraiment, c'est un sujet digne des livres.
Heureusement, il existe un tel livre: " The Art of Capacity Planning "
Pour développer le post de Mark Henderson, j'écris ceci spécifiquement pour Apache. Pour réitérer ce qu'il a dit, "La réponse courte est: personne ne peut répondre à cette question sauf vous." Le texte de cette réponse est largement emprunté à ma réponse à une question similaire à propos d'un performance du site Drupal .
Configuration d'Apache avec Mod_Prefork
Apache est sans doute l'un des (sinon le) serveur Web le plus populaire disponible. Il est open source et est toujours activement maintenu. Vous pouvez l'exécuter sur les systèmes d'exploitation Linux et Windows, mais il est plus populaire dans le monde Linux/Unix.
Vous ne devez jamais utiliser une configuration Apache prête à l'emploi. Vous devez toujours régler Apache sur votre site. Le fichier principal configuration Apache sur CentOS se trouve à /etc/httpd/conf/httpd.conf, et le fichier de configuration principal d'Apache sur les systèmes Ubuntu se trouve généralement à /etc/Apache2/Apache2.conf. Des fichiers de configuration supplémentaires sont utilisés pour des choses comme Virtual Hosts .
Comme beaucoup de logiciels, Apache est conçu pour être flexible et personnalisé en fonction des besoins d'un site Web spécifique. Il existe différents modules de multi-traitement qu'Apache peut être configuré pour utiliser pour se lier à un port réseau et accepter et traiter les demandes.
La plupart du temps sur les installations Apache par défaut fournies avec les serveurs CentOS et Ubuntu, le MPM " mod_prefork " est utilisé. En supposant que vous utilisez mod_prefork (si vous n'êtes pas sûr, c'est le plus probable, mais vous seul pouvez le déterminer) Voici les bases de la configuration:
- Déterminez la quantité maximale de mémoire que vous souhaitez qu'Apache puisse utiliser.
- Testez fortement votre site Web et déterminez la quantité de mémoire utilisée par chaque processus Apache (en utilisant top).
- Prenez le processus Apache en haut qui utilise le plus de mémoire, ajoutez-y un peu pour faire bonne mesure, puis divisez votre premier nombre (quantité maximale de mémoire que vous souhaitez qu'Apache utilise) par ce nouveau numéro.
- Le nombre que vous obtenez doit être vos variables
MaxClients&ServerLimit.
Ce n'est certainement pas la réponse définitive. Ajuster votre serveur Apache prend du temps et nécessite de l'expérience pour bien fonctionner.
Je suggère également de parler aux architectes et ingénieurs qui ont conçu/construit les applications pour essayer d'identifier les goulots d'étranglement, les points de défaillance uniques et les limitations de licence.