la réponse de womble est impressionnante, quoique un peu difficile à comprendre et à appliquer pour les inexpérimentés. Je voudrais donner quelques chiffres empiriques et une comparaison des applications "contenu simple" et "commerce électronique".
Il n'y a pas beaucoup de matériel autour de la définition de différents cas d'utilisation par rapport à leur configuration appropriée de mod_wsgi, donc j'espère que c'est correct d'utiliser un peu de prose ici.
A) Sites CMS et microsites
Nous gérons plusieurs sites Web clients, la plupart d'entre eux principalement des sites de contenu ou des micro-sites hébergeant django CMS, certains formulaires personnalisés et parfois Celery pour les tâches d'arrière-plan planifiées. Ces sites n'ont pas faim de ressources, plusieurs d'entre eux fonctionnent heureusement en parallèle sur un seul Intel Xeon à 4 cœurs avec 32 Go de RAM. Voici la configuration que nous utilisons pour chacun de ces types de sites:
WSGIDaemonProcess example.com user=www-data processes=2 maximum-requests=100
Je parle d'environ 40 sites sur un seul serveur, la plupart d'entre eux avec leur site Staging en veille. Avec 2 processus (ayant 15 threads chacun, par défaut), les sites sont aisés, bien que limités dans leur capacité d'allocation des ressources du serveur. La raison pour laquelle cette configuration est suffisante peut être justifiée par la nature simple de l'application (CMS): aucune demande ne devrait prendre plus de quelques millisecondes. Apache restera toujours détendu, tout comme la charge CPU.
B) Sites de commerce électronique
Les sites plus complexes que nous réalisons se caractérisent par des opérations locales encore peu coûteuses en termes de calcul mais des dépendances externes (par exemple, des services Web fournissant des données de réservation) qui sont coûteuses en termes de temps de transaction. Les opérations avec des demandes externes occupent des threads beaucoup plus longtemps, vous avez donc besoin de plus de threads pour répondre au même nombre d'utilisateurs (par rapport à un simple site CMS ci-dessus). Pire encore, les threads sont parfois bloqués lorsqu'un service externe ne peut pas répondre immédiatement à une demande, parfois pendant quelques secondes. Cela peut entraîner l'effet secondaire désagréable que les threads plaçant des demandes vers la même file d'attente de service, jusqu'à ce que tous les threads mod_wsgi disponibles soient utilisés et bloqués en attente.
Pour ces scénarios, nous avons essayé d'utiliser des 6
processus sans voir beaucoup de différence, et nous nous sommes retrouvés avec 12
une amélioration incomparable des performances et de la stabilité opérationnelle:
WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100
Certains tests de charge simples avec 150 et 250 utilisateurs parallèles sont facilement gérés par le site en restant bien réactifs (tandis qu'avec les 2
processus, le site est inutilisable et traite 50 utilisateurs en parallèle). Les 2 CPU 6 Core Intel Xeon avec 32 Go de RAM fonctionnent bien en dessous de 25% d'utilisation du CPU sous cette charge, l'utilisation de la RAM reste presque constante à moins de 25% également. Notez que nous utilisons une machine dédiée uniquement pour un seul site ici, donc nous ne volerons pas les ressources dont d'autres sites pourraient avoir besoin.
Conclusion
L'utilisation d'un plus grand nombre de processus est un compromis entre permettre ou non à Apache d'utiliser les ressources système disponibles. Si vous voulez garder un système de serveur stable (pas un site Web!) Dans des conditions "d'attaque", gardez le nombre bas. Si vous souhaitez qu'Apache vous aide à utiliser les ressources système (CPU, RAM) en cas de besoin, choisissez un nombre plus élevé. La hauteur à laquelle vous pouvez aller calcule un peu comme indiqué dans la réponse acceptée ci-dessus, et est finalement limitée par la puissance CPU et la RAM disponibles.
(PS: je garde la section ConfigurationDirectives du wiki du projet modwsgi sous mon oreiller pour une lecture en arrière-plan comme Apache. Assurez-vous également de comprendre et de surveiller les connexions ouvertes de votre serveur Apache .)