Скажем, у меня есть 2 сайта (Superuser и Serverfault), запущенные с их собственного виртуального хоста Apache на одном компьютере. 2 сайта работают на Django и на Apache с mod-wsgi. Типичный файл конфигурации для одного из сайтов будет выглядеть следующим образом:
WSGIDaemonProcess serverfault.com user=www-data group=www-data processes=5
Хост - это Linux-машина с 4 ГБ оперативной памяти под управлением Ubuntu. Может ли кто-нибудь предложить количество процессов, которые я должен указать выше для моих двух сайтов? Предположим, у них такой же трафик, как у фактических сайтов Superuser и Serverfault.
Ну сколько трафика делать у реальных сайтов Superuser и Serverfault есть? Гипотетические гипотезы бесполезны, если у них недостаточно информации, чтобы облегчить ответ ...
Счетчик процессов в наихудшем случае должен быть пиковым количеством запросов в секунду, которое вы хотите, чтобы сайт мог обрабатывать, деленным на количество запросов в секунду, которые может обработать один процесс, если все эти запросы относятся к вашему самому медленному действию (так величина, обратная времени обработки этого действия). Добавьте любой коэффициент ошибочности, который вы считаете подходящим, на основе доверительного интервала ваших запросов в секунду и измерений времени.
Среднее количество обращений такое же, но вы делите количество запросов в секунду на средневзвешенное число запросов в секунду для каждого действия (вес - это процент запросов, которые, как вы ожидаете, выполнят это конкретное действие). Опять же, полезны ложные факторы.
Фактическая верхняя граница количества процессов, которые вы можете запустить на машине, определяется максимальным объемом памяти, который занимает каждый процесс; запустите один процесс, а затем выполните множество действий, требующих большого объема памяти (обычно те, которые извлекают и обрабатывают большой объем данных) против него с реалистичным набором данных (если вы просто используете игрушечный набор данных для тестирования, скажем, 50 или 100 rows, то, если одно из ваших действий извлекает и манипулирует каждой строкой в таблице, это не будет хорошим измерением, когда эта таблица вырастет до 10 000 строк), чтобы увидеть, до чего вырастает использование памяти. Вы можете искусственно ограничить использование памяти для каждого процесса с помощью сценария, который перехватывает рабочих, достигших определенного порога использования памяти, с риском возникновения неприятных проблем, если вы установите этот порог слишком низко.
После того, как у вас есть показатель использования памяти, вы вычитаете некоторый объем памяти для накладных расходов системы (мне нравится 512 МБ), вычитаете кучу больше, если у вас есть другие процессы, запущенные на том же компьютере (например, база данных), а затем еще немного, чтобы убедиться, что у вас не закончилось место в кеш-памяти (зависит от размера рабочего набора вашего диска, но опять же, я бы выбрал не менее 512 МБ). Это объем памяти, который вы делите на использование памяти каждым процессом, чтобы получить потолок.
Если количество процессов, необходимых для обслуживания пиковой нагрузки, превышает количество процессов, которые вы можете разместить в коробке, вам нужно больше машин (или, в простейшем случае, переместить базу данных на другую машину).
Вот и вы, несколько лет опыта масштабирования веб-сайтов, сведенных в один небольшой и простой пост в SF.
WombleОтвет потрясающий, хотя и немного сложный для понимания и применения для неопытных. Я хотел бы привести некоторые эмпирические цифры и сравнение приложений «простой контент» и «электронная коммерция».
Не так много материала по настройке различных вариантов использования в зависимости от их соответствующей конфигурации mod_wsgi, поэтому я надеюсь, что здесь можно использовать небольшую прозу.
У нас есть несколько веб-сайтов клиентов, большинство из которых в основном контентные или микросайты, на которых размещается django CMS, некоторые пользовательские формы, а иногда и Celery для запланированных фоновых задач. Эти сайты не нуждаются в ресурсах, некоторые из них успешно работают параллельно на одном четырехъядерном процессоре 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 пользователей параллельно). Двухъядерный 6-ядерный Intel Xeon с 32 ГБ оперативной памяти работает при такой нагрузке значительно ниже 25% использования ЦП, использование оперативной памяти почти остается постоянным и составляет менее 25%. Обратите внимание, что здесь мы используем выделенный компьютер только для одного сайта, поэтому мы не будем красть ресурсы, которые могут понадобиться другим сайтам.
Использование большего количества процессов - это компромисс между разрешением Apache использовать доступные системные ресурсы или нет. Если вы хотите сохранить стабильную серверную систему (не веб-сайт!) В условиях «атаки», держите это число на низком уровне. Если вы хотите, чтобы Apache помогал вам использовать системные ресурсы (ЦП, ОЗУ), когда это необходимо, выберите большее число. То, насколько высоко вы можете подняться, рассчитывается примерно так, как указано в принятом ответе выше, и в конечном итоге ограничивается доступной мощностью процессора и оперативной памяти.
(P.S .: Я держу Раздел ConfigurationDirectives вики проекта modwsgi под моей подушкой для фонового чтения в стиле Apache. Также убедитесь, что понимаете и следите за своим Открытые соединения сервера Apache.)