C'est une question canonique sur la planification de la capacité des sites Web.
Apparenté, relié, connexe:
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, infrastructures, etc., ainsi que les meilleures pratiques applicables aux serveurs Web en général.
Réponses:
La réponse courte est: personne ne peut répondre à cette question sauf vous.
La réponse longue est que l’analyse de votre charge de travail spécifique est quelque chose que vous devez entreprendre vous-même, car c’est un peu comme si vous demandiez "Combien de temps dure une ficelle?".
Un simple site Web statique d'une page peut être hébergé sur un Pentium Pro 150 et toujours générer des milliers d'impressions chaque jour.
L’approche de base à 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 afin de voir où il se déforme.
Un bref aperçu de ceci est:
Fondamentalement, afin de tester une charge, vous avez besoin de quelque chose à tester. Configurez un environnement à tester. Cela devrait être une approximation assez proche de votre matériel de production si possible, sinon vous ne pourrez plus extrapoler vos données.
Configurez vos serveurs, vos comptes, vos sites Web, votre bande passante, etc. Même si vous le faites sur des ordinateurs virtuels, tout va bien tant que vous êtes prêt à faire évoluer vos résultats.
Je vais donc 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é, haproxydans 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 avec contrainte l'équilibreur de charge. Ces deux serveurs Web sont configurés de manière identique à mes systèmes en direct.
Vous aurez besoin de certaines mesures à surveiller. Je vais donc mesurer le nombre de demandes qui parviennent à mes serveurs Web et le nombre de demandes 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 également surveiller l'utilisation de la RAM, du processeur et du disque sur l' haproxyinstance afin de m'assurer que l'équilibreur de charge peut gérer les connexions.
Comment faire cela dépend beaucoup de vos plates-formes et sort du cadre de cette réponse. Vous devrez peut-être consulter les fichiers journaux du serveur Web, démarrer des compteurs de performance ou vous fier à la capacité de création de rapports de votre outil de test de stress.
Quelques choses que vous voulez toujours surveiller:
Vous pouvez également choisir de regarder les blocages SQL, les temps de recherche, etc. en fonction de ce que vous testez spécifiquement.
C'est là que les choses s'amusent. Vous devez maintenant simuler une charge de test. Il existe de nombreux outils pour ce faire, avec des options configurables:
Choisissez un nombre, n'importe quel nombre. Disons que vous allez voir comment le système répond avec 10 000 hits par minute. Le numéro 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épond.
Dans l'idéal, 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 de demandes. Par exemple, le test à distance de JMeter fournit une interface centrale à partir de laquelle lancer plusieurs clients à partir d'un ordinateur Jmeter contrôlant.
Appuyez sur le bouton magique Go et regardez vos serveurs Web fondre et se bloquer.
Vous devez donc maintenant revenir aux mesures que vous avez collectées à l'étape 2. Vous voyez qu'avec 10 000 connexions simultanées, votre haproxyboîte ne fait que transpirer, mais le temps de réponse avec deux serveurs Web prend un peu plus de cinq secondes. Ce n'est pas cool - rappelez-vous que votre temps de réponse est de deux secondes. Nous devons donc apporter des changements.
Maintenant, vous devez accélérer votre site Web de plus de deux fois. Donc, vous savez que vous devez soit augmenter, soit augmenter.
Pour évoluer, utilisez des serveurs Web plus grands, plus de RAM, des disques plus rapides.
Pour évoluer, obtenez plus de serveurs.
Utilisez les métriques de l'étape 2 et les tests pour prendre cette décision. Par exemple, si vous avez constaté que la latence du disque était importante pendant les tests, vous savez que vous devez augmenter la taille et obtenir des disques durs plus rapides.
Si vous avez constaté que le processeur était à 100% pendant le test, vous devrez peut-être augmenter la capacité pour ajouter des serveurs Web supplémentaires afin de réduire la pression exercée 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 d’intensifier et si cela ne fonctionne pas, augmentez à la place. Ou pas, c'est à vous et à certains de sortir des sentiers battus.
Disons que nous allons passer à la vitesse supérieure. J'ai donc décidé de cloner mes deux serveurs Web (ce sont des ordinateurs virtuels) 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 délais de réponse sont toujours supérieurs à deux secondes), puis examinez les autres goulots d'étranglement. Par exemple, vous avez doublé les serveurs Web, mais vous disposez toujours d'un serveur de base de données de mauvaise qualité. Ou bien, vous avez cloné plus de machines virtuelles, mais comme elles se trouvent sur le même hôte physique, vous n’avez obtenu que des conflits plus importants pour les ressources des serveurs.
Vous pouvez ensuite utiliser cette procédure pour tester d'autres parties du système. Au lieu d'appuyer sur 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 par rapport à la charge. Une fois que vous savez à quel point les programmes ralentissent avec la charge, ce qui n'est PAS une fonction linéaire, vous pouvez sélectionner une cible de temps de réponse, puis découvrir les ressources nécessaires pour atteindre cette cible pour une charge donnée.
La mesure de la performance est toujours effectuée avec des unités de temps , comme
Des éléments tels que% CPU et IOPS sont spécifiques au système. Vous ne les utilisez donc que lorsque vous avez planifié le système et l'avoir mesuré en pré-production, pour agir en tant que "substitut" de ce qui vous tient à cœur, le temps.
La planification de la capacité est une bête gênante. C'est autant la science que l'art (même s'il est vraiment sombre).
Votre meilleur cas est que vous preniez des décisions éclairées et que fortune / chance vous favorise en permettant à la réalité de répondre à vos hypothèses. Si vos hypothèses en matière 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épassé et dépassé. Plus malheureusement, si vos hypothèses sont en deçà de la réalité éventuelle (ou sont incorrectes par ailleurs), vous manquerez de la capacité dont vous avez besoin et vous devrez vous démener pour atténuer les défaillances de votre infrastructure gémissante, ce qui vous fera ressembler à un manque de compétence.
Pas de pression...
Malheureusement, l'art sombre de la planification de la capacité est plus que ce qui peut raisonnablement être distillé dans une réponse unique Server Fault; vraiment, c'est un sujet digne des livres.
Heureusement, il existe un tel livre: " L'art de la planification des capacités "
Pour développer le post de Mark Henderson, j'écris ceci spécifiquement à Apache. Pour réitérer ce qu’il a dit, "La réponse courte est: Personne ne peut répondre à cette question à l’exception de vous." Le texte de cette réponse est largement emprunté à ma réponse à une question similaire sur les performances d' un site Web Drupal .
Apache est sans doute l’un des serveurs Web les plus populaires (sinon le) 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 est plus populaire dans le monde Linux / Unix.
Vous ne devriez jamais utiliser une configuration Apache prête à l'emploi. Vous devez toujours adapter Apache à votre site. Le fichier de configuration Apache principal sur CentOS se trouve à l'emplacement /etc/httpd/conf/httpd.conf, et le fichier de configuration Apache principal sur les systèmes Ubuntu, à l'emplacement suivant /etc/apache2/apache2.conf. Des fichiers de configuration supplémentaires sont utilisés pour des choses comme les hôtes virtuels .
Comme beaucoup de logiciels, Apache est conçu pour être flexible et personnalisé en fonction des besoins d’un site Web spécifique. Apache peut être configuré pour utiliser différents modules de multitraitement afin de se lier à un port réseau et d'accepter et de traiter les demandes.
Le plus souvent, sur les installations Apache par défaut fournies avec les serveurs CentOS et Ubuntu, le MPM " mod_prefork " est utilisé. En supposant que vous utilisiez 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:
MaxClients& ServerLimitvariables.Ce n'est certainement pas la solution finale. Le réglage de votre serveur Apache prend du temps et nécessite de l'expérience pour réussir.