Il s'agit d'un question canonique sur la planification de la capacité des sites web.
En rapport :
Quels sont les outils et les méthodes recommandés pour la planification de la capacité des sites 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'évaluation 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 bout de ficelle ?".
Un simple site web statique d'une page pourrait être hébergé sur un Pentium Pro 150 et servir des milliers d'impressions chaque jour.
L'approche de base que vous devez adopter pour répondre à cette question est la suivante essayez et voir ce qui se passe. Il existe de nombreux outils que vous pouvez utiliser pour mettre artificiellement votre système sous pression et voir où il cède.
En voici un bref aperçu :
Fondamentalement, pour tester une charge, vous avez besoin de quelque chose à tester. Créez un environnement de test. Il doit être 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 faites cela sur des machines virtuelles, cela ne pose aucun problème tant que vous êtes prêt à faire évoluer vos résultats.
Je vais donc configurer une machine virtuelle de puissance moyenne (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 de Red Hat Linux sur la VM.
Je vais également avoir deux serveurs web derrière l'équilibreur de charge que je vais utiliser pour tester l'équilibreur de charge. Ces deux serveurs web sont configurés de la même manière que mes systèmes réels.
Vous aurez besoin de certains paramètres à surveiller. Je vais donc mesurer le nombre de requêtes qui parviennent à mes serveurs web et le nombre de requêtes que je peux faire passer par seconde avant que les utilisateurs ne commencent à obtenir un temps de réponse de plus de deux secondes.
Je vais aussi surveiller l'utilisation de la RAM, du CPU et du disque sur le serveur. haproxy pour s'assurer que l'équilibreur de charge peut gérer les connexions.
La manière de procéder dépend beaucoup de vos plateformes et n'entre pas dans le cadre de cette réponse. Vous devrez peut-être examiner les fichiers journaux du serveur Web, lancer des compteurs de performance ou vous fier à la capacité de rapport de votre outil de test de stress.
Quelques éléments à surveiller en permanence :
Vous pouvez également choisir d'examiner les blocages SQL, les temps de recherche, etc. en fonction de ce que vous testez spécifiquement.
C'est là que les choses deviennent amusantes. Vous devez maintenant simuler une charge de test. Il y a de nombreux outils qui peut le faire, avec des options configurables :
Choisissez un numéro, n'importe quel numéro. Disons que vous allez voir comment le système réagit avec 10 000 visites par minute. Le nombre que vous choisissez n'a pas d'importance, car vous allez répéter cette étape plusieurs fois, en ajustant ce nombre à la hausse ou à la baisse pour voir comment le système réagit.
Idéalement, vous devriez 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, la fonction de test de charge de JMeter Test à distance fournit une interface centrale à partir de laquelle il est possible de lancer plusieurs clients depuis une machine Jmeter de contrôle.
Appuyez sur le bouton magique Allez sur et regardez vos serveurs web s'effondrer.
Vous devez maintenant revenir aux mesures que vous avez recueillies à l'étape 2. Vous voyez qu'avec 10,000 connexions simultanées, votre haproxy est à peine en train de transpirer, mais le temps de réponse avec deux serveurs web est légèrement supérieur à cinq secondes. Ce n'est pas cool - rappelez-vous que votre temps de réponse est de deux secondes. Nous devons donc procéder à quelques changements.
Maintenant, vous devez accélérer votre site web de plus du double. Vous savez donc que vous devez soit augmenter, soit diminuer.
Pour monter en puissance, il faut des serveurs web plus grands, plus de RAM, des disques plus rapides.
Pour passer à l'échelle supérieure, il faut acheter plus de serveurs.
Utilisez vos mesures de l'étape 2, et les tests, pour prendre cette décision. Par exemple, si vous avez constaté que la latence du disque était massive pendant les tests, vous savez que vous devez passer à la vitesse supérieure et acheter des disques durs plus rapides.
Si vous constatez que le processeur est resté à 100 % pendant le test, il est peut-être nécessaire d'ajouter des serveurs Web supplémentaires pour 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 est bon pour vous. Essayez de passer à l'échelle supérieure, et si cela ne fonctionne pas, passez à l'échelle inférieure. Ou pas, c'est à vous de voir et de sortir des sentiers battus.
Disons que nous allons changer d'échelle. Je décide donc de cloner mes deux serveurs web (ce sont des VM) et j'ai maintenant quatre serveurs web.
Recommencez à partir de l'étape 3. Si vous constatez que les choses ne se passent pas comme prévu (par exemple, nous avons doublé les serveurs Web, mais les temps de réponse sont toujours supérieurs à deux secondes), recherchez d'autres goulots d'étranglement. Par exemple, vous avez doublé le nombre de serveurs Web, mais vous avez toujours un serveur de base de données médiocre. Ou encore, vous avez cloné davantage de machines virtuelles, mais comme elles se trouvent sur le même hôte physique, vous n'avez obtenu qu'une plus grande concurrence 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 en utilisant un outil de benchmarking SQL .
La planification des capacités commence par une mesure, dans ce cas le temps de réponse en fonction de la charge. Une fois que vous savez dans quelle mesure les programmes ralentissent avec la charge, ce qui n'est PAS une fonction linéaire, vous pouvez choisir un objectif de temps de réponse, puis découvrir quelles ressources il faudra pour atteindre cet objectif pour une quantité donnée de charge.
La mesure de la performance se fait toujours avec temps unités, comme
Des éléments tels que le %CPU et les IOPS sont spécifiques au système. Vous ne les utilisez donc que lorsque vous avez planifié le système et que vous l'avez mesuré en pré-production, pour servir de "substitut" à la chose qui vous intéresse, le temps.
La planification de la capacité est une bête difficile. C'est autant une science qu'un art (même si c'est un art sombre).
Dans le meilleur des cas, vous prenez des décisions éclairées. y la chance vous favorise en faisant en sorte que la réalité corresponde à vos hypothèses. Si vos hypothèses de besoin de capacité correspondent à la réalité, vous ressemblez à un yogi mystique. Malheureusement, si vos hypothèses dépassent la réalité, vous aurez l'air d'avoir dépassé les limites et d'avoir trop dépensé. Plus malheureusement encore, si vos hypothèses sont inférieures à la réalité éventuelle (ou si elles sont par ailleurs incorrectes), vous manquerez de la capacité dont vous avez besoin et devrez vous démener pour atténuer les défaillances de votre infrastructure qui gémit, ce qui vous fera passer pour quelqu'un qui manque de compétence.
Pas de pression...
Malheureusement, l'art obscur de la planification de la capacité est plus que ce qui peut être raisonnablement distillé dans une seule réponse à Server Fault ; en fait, c'est un sujet qui mérite des livres.
Heureusement, un tel livre existe : " L'art de la planification des capacités "
Pour développer l'article 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 sur un projet de Performances du site Drupal .
Apache est sans doute l'un des serveurs web les plus populaires (si ce n'est le plus populaire). 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 devez nunca utiliser une configuration Apache prête à l'emploi. Vous devez toujours adapter Apache à votre site. Les principaux Configuration d'Apache sous CentOS est situé à /etc/httpd/conf/httpd.conf Le fichier de configuration principal d'Apache sur les systèmes Ubuntu se trouve généralement à l'adresse suivante /etc/apache2/apache2.conf . Des fichiers de configuration supplémentaires sont utilisés pour des choses comme Hôtes virtuels .
Comme beaucoup de logiciels, Apache est conçu pour être flexible et personnalisé en fonction des besoins spécifiques d'un site web. Il existe différents modules de multitraitement qu'Apache peut être configuré pour utiliser afin de se lier à un port réseau et accepter et traiter les requêtes.
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 sa configuration :
MaxClients & ServerLimit variables.Il ne s'agit certainement pas d'une réponse définitive. Optimisation de votre serveur Apache prend du temps et nécessite de l'expérience pour l'obtenir.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
