Відповідь жінки є приголомшливою, хоч і трохи важкою для розуміння та подання заявки на недосвідченого. Я хотів би дати кілька емпіричних цифр та порівняння програм "простий вміст" та "електронна комерція".
Немає багато матеріалу щодо встановлення різних випадків використання стосовно їх відповідної конфігурації mod_wsgi, тому я сподіваюся, що тут добре використовувати трохи прози.
A) CMS-сайти та мікросайти
Ми запускаємо декілька веб-сайтів клієнтів, більшість з яких в основному вміст-сайти або мікро-сайти, що розміщують Django CMS, деякі спеціальні форми, а іноді і селера для запланованих фонових завдань. Ці сайти не прагнуть ресурсів, декілька з них щасливо працюють паралельно на одному 4-ядерному Intel Xeon з 32 ГБ оперативної пам’яті. Ось конфігурація, яку ми використовуємо для кожного з таких сайтів:
WSGIDaemonProcess example.com user=www-data processes=2 maximum-requests=100
Я говорю про приблизно 40 сайтів на одному сервері, більшість із яких розміщують свій сайт, який працює в режимі очікування. З двома процесами (що мають 15 потоків у кожній за замовчуванням) сайти є добре забезпеченими, хоча й обмеженими можливостями розподілу серверних ресурсів. Чому така настройка є достатньою, можна виправдати простий характер програми (CMS): жоден запит не повинен зайняти більше ніж пару мілісекунд. Apache завжди залишатиметься розслабленим, і таким буде навантаження на процесор.
Б) Сайти електронної комерції
Більш складні веб-сайти, які ми робимо, характеризуються все ще недорогими локальними операціями, але зовнішніми залежностями (наприклад, веб-сервісами, що надають дані бронювання), які є дорогими з точки зору часу трансакції. Операції із зовнішніми запитами займають потоки набагато довший час, тому вам потрібно більше потоків, щоб задовольнити однакову кількість користувачів (порівняно з простим сайтом CMS зверху). Ще гірше, що потоки час від часу блокуються, коли зовнішня служба не може відповісти на запит негайно, іноді на пару секунд. Це може призвести до неприємного побічного ефекту від того, що потоки, що розміщують запити в ту саму чергу обслуговування, доти, поки всі наявні потоки mod_wsgi не будуть використані та заблоковані в очікуванні.
Для цих сценаріїв ми намагалися використовувати 6процеси, не бачачи великої різниці, і в кінцевому підсумку ми 12побачили незрівнянне підвищення продуктивності та стабільності роботи:
WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100
Деякі прості навантажувальні тести на 150 і 250 паралельних користувачів легко обробляються сайтом, залишаючись добре чуйними (в той час як для 2процесів сайт непридатний для обслуговування 50 користувачів паралельно). 2-ядерний процесор 6-ядерний Intel Xeon з 32 ГБ оперативної пам’яті працює значно нижче 25% використання процесора при цьому навантаженні, також використання оперативної пам’яті майже залишається постійним і становить менше 25%. Зауважте, що ми використовуємо спеціалізовану машину лише для одного сайту, тому ми не будемо красти ресурси, які можуть знадобитися іншим сайтам.
Висновок
Використання більшої кількості процесів є компромісом між тим, чи дозволяти Apache використовувати доступні системні ресурси чи ні. Якщо ви хочете зберегти стабільну серверну систему (не веб-сайт!) В умовах "атаки", збережіть число низьким. Якщо ви хочете, щоб Apache допомогло вам використовувати системні ресурси (процесор, оперативну пам’ять), коли потрібно, виберіть більшу кількість. Наскільки високо ви можете підраховувати, дещо схоже на викладене у прийнятій відповіді вище, і в кінцевому рахунку обмежується наявною потужністю процесора та оперативною пам’яттю.
(PS: Я зберігаю розділ ConfigurationDirectives у вікі проекту modwsgi під подушкою для читання фоном Apache. Також не забудьте зрозуміти та відслідковувати відкриті підключення сервера Apache .)