Comments 24
спасибо за статью. попробую обязательно. однако лично я ставлю под сомнение целесообразность установки на боевую машину модуль который не обновлялся более года. неужели за этот год не выпустили ничего аналогичного?
А чем не устраивает стандартный способ — mod_wsgi к апачу + когда понадобится — ngnix в качестве фронт-энда\для статики? Оверхед в случае апача небольшой, если вообще есть (по сути — это 1 лишний родительский процесс и все).
Ведь треды-процессы mod_wsgi апачевского — независимые, и апача самого в себе не содержат.
А тут непонятно, как обходить эту самую «ложку дегтя».
Ведь треды-процессы mod_wsgi апачевского — независимые, и апача самого в себе не содержат.
А тут непонятно, как обходить эту самую «ложку дегтя».
Апач много памяти сам по себе жрет, на всяких VDS это может очень сказаться.
Сейчас глянул к себе на VDS — процесс апача, который обслуживает сайт, к которому никто не ходит, занимает 6 метров RES-памяти. Это, собственно, все лишние расходы на 1 сайт. Я ничего хитро не компилировал и т.д., просто оставил только нужные модули (mod_wsgi, mod_fastcgi, еще по мелочи).
Сколько точно?
Сколько-то памяти лишней апачь все равно скушает, настройки требует, лишняя сущность как ни как.
А насчет ложки дегтя — при любой настройке есть 2 варианта — либо мы не ограничиваем количество приложений и при нагрузке они плодятся, пожирая память и уводя систему в даун. Либо мы ограничиваем количество количество приложений и они встают в очередь. Только тут мы получаем в нагрузку неприятный эффект — небольшую задержку пока не освободиться хотябы один воркер. Да только в любом случае следующую порцию статики инджиникс отдаст прежде чем возмется за следующую динамику.
А насчет ложки дегтя — при любой настройке есть 2 варианта — либо мы не ограничиваем количество приложений и при нагрузке они плодятся, пожирая память и уводя систему в даун. Либо мы ограничиваем количество количество приложений и они встают в очередь. Только тут мы получаем в нагрузку неприятный эффект — небольшую задержку пока не освободиться хотябы один воркер. Да только в любом случае следующую порцию статики инджиникс отдаст прежде чем возмется за следующую динамику.
1. Ну насчет настройки, с одной стороны, все верно, лишняя сущность, но с другой — чего там в апаче настраивать-то, по сравнению с предложенным способом)
2. Теперь насчет памяти. В случае с процессами-воркерами ngnix, как я понимаю (поправьте, если не так), в каждый процесс будет грузиться как минимум интерпретатор питона. Или нет? Апачевский mod_wsgi работает с shared-версией питоновских библиотек, в итоге каждый его процесс представляет из себя 250 килобайт собственно кода mod_wsgi + загруженное приложение (сайт на джанге, например). Я так себе представляю. Так что и потребление памяти еще посчитать стоит, где больше.
3. Насчет ложки дегтя. Если на VDS том же крутятся несколько сайтов, то выгоднее всем ограничить число плодящихся процессов, а изначально запускать их меньше, чем это макс. ограничение, так что сайты смогут переживать пиковые нагрузки с одной стороны, и не кушать много памяти без надобности с другой. Апачевский mod_wsgi в этом плане довольно гибок — может использовать как апачевские модели порождения процессов и тредов, так и свои. Если ngnix'овые воркеры тоже умеют запускаться по необходимости, то все отлично. А если нет, то вот что выходит: сам сайт на джанге ест в большинстве случаев памяти больше, чем выражение (размер процесса апача — размер процесса ngnix), поэтому даже одна лишняя копия сайта в памяти может убить все преимущество ngnix.
4. Еще раз, насчет памяти, которую скушает апач. Это скорее штука психологическая. Ведь все знают, что апач жрет кучу памяти. Но лучше знать цифры. Если критично 6 (или сколько там) мегабайт на 1 сайт (не на 1 процесс, на сайт) — то да, есть смысл искать что-то другое. Как мне кажется, это критично только если хостится куча сайтов на одном VDS или сервере (кстати, тут см. п3, про ложку дегтя). А для одного сайта с высокой нагрузкой это не критично совершенно, тут важнее надежность и гибкость апачевского mod_wsgi, а так же то, что накладные расходы на процесс/тред минимальны.
Все это ни в коем случае не умаляет важность и полезность статьи, полезно знать, как настроить mod_wsgi ngnix-овский, просто важно обозначить, зачем и когда это нужно.
2. Теперь насчет памяти. В случае с процессами-воркерами ngnix, как я понимаю (поправьте, если не так), в каждый процесс будет грузиться как минимум интерпретатор питона. Или нет? Апачевский mod_wsgi работает с shared-версией питоновских библиотек, в итоге каждый его процесс представляет из себя 250 килобайт собственно кода mod_wsgi + загруженное приложение (сайт на джанге, например). Я так себе представляю. Так что и потребление памяти еще посчитать стоит, где больше.
3. Насчет ложки дегтя. Если на VDS том же крутятся несколько сайтов, то выгоднее всем ограничить число плодящихся процессов, а изначально запускать их меньше, чем это макс. ограничение, так что сайты смогут переживать пиковые нагрузки с одной стороны, и не кушать много памяти без надобности с другой. Апачевский mod_wsgi в этом плане довольно гибок — может использовать как апачевские модели порождения процессов и тредов, так и свои. Если ngnix'овые воркеры тоже умеют запускаться по необходимости, то все отлично. А если нет, то вот что выходит: сам сайт на джанге ест в большинстве случаев памяти больше, чем выражение (размер процесса апача — размер процесса ngnix), поэтому даже одна лишняя копия сайта в памяти может убить все преимущество ngnix.
4. Еще раз, насчет памяти, которую скушает апач. Это скорее штука психологическая. Ведь все знают, что апач жрет кучу памяти. Но лучше знать цифры. Если критично 6 (или сколько там) мегабайт на 1 сайт (не на 1 процесс, на сайт) — то да, есть смысл искать что-то другое. Как мне кажется, это критично только если хостится куча сайтов на одном VDS или сервере (кстати, тут см. п3, про ложку дегтя). А для одного сайта с высокой нагрузкой это не критично совершенно, тут важнее надежность и гибкость апачевского mod_wsgi, а так же то, что накладные расходы на процесс/тред минимальны.
Все это ни в коем случае не умаляет важность и полезность статьи, полезно знать, как настроить mod_wsgi ngnix-овский, просто важно обозначить, зачем и когда это нужно.
Про психологический фактор, это вы верно сказали.
В «похожих публикациях» есть две статьи, которые я очень внимательно изучал до моих экспериментов. В первой автор рассказывает, как в условиях VDS, экономя память, сначала отказался от mod_python в пользу apache+mod_wsgi, а во второй, как отказался от apache в пользу проксирования сетнд-элон сервера на питоне. Хотя да, я сам еще не пробовал mod_wsgi для апача, возможно его и можно оттюнинговать. Теперь обязательно этим займусь.
В «похожих публикациях» есть две статьи, которые я очень внимательно изучал до моих экспериментов. В первой автор рассказывает, как в условиях VDS, экономя память, сначала отказался от mod_python в пользу apache+mod_wsgi, а во второй, как отказался от apache в пользу проксирования сетнд-элон сервера на питоне. Хотя да, я сам еще не пробовал mod_wsgi для апача, возможно его и можно оттюнинговать. Теперь обязательно этим займусь.
Прочитал обе статьи.
Там неясно, с какими параметрами запускалось все в обоих случаях, так что прямое сравнение бессмысленно проводить. Похоже, в mod_wsgi было 15 тредов на сайт, а с fapsw — 1 процесс на сайт, естественно сайт в первом случае занимал раз в 15 больше памяти.
Запустили бы mod_wsgi с одним процессом и 1 тредом, а статику отдавали бы ngnix'ом — было бы сравнение mod_wsgi и fapsw на одних настройках. И неизвестно, что бы оказалось лучше. В любом случае, разница была бы крошечная, думаю.
А что касается производительности — упирается все обычно уж точно не в способ организации wsgi-взаимодействия. Все эти тесты про 10000 запросов в секунду vs 1000 запросов в секунду имеют значение только для статики, в случае приложения, которое что-то делает, коннектится к базе той же, это просто абсолютно незаметная мелочь.
Миф о раздутости апача, думаю, во многом происходит от mod_php. Когда в каждый процесс апача, отдающий статику, встраивается такая бандура и быстро сжирает всю память, а потом запускаешь все на ngnix+fastcgi и радуешься жизни, осадочек-то остается.
Там неясно, с какими параметрами запускалось все в обоих случаях, так что прямое сравнение бессмысленно проводить. Похоже, в mod_wsgi было 15 тредов на сайт, а с fapsw — 1 процесс на сайт, естественно сайт в первом случае занимал раз в 15 больше памяти.
Запустили бы mod_wsgi с одним процессом и 1 тредом, а статику отдавали бы ngnix'ом — было бы сравнение mod_wsgi и fapsw на одних настройках. И неизвестно, что бы оказалось лучше. В любом случае, разница была бы крошечная, думаю.
А что касается производительности — упирается все обычно уж точно не в способ организации wsgi-взаимодействия. Все эти тесты про 10000 запросов в секунду vs 1000 запросов в секунду имеют значение только для статики, в случае приложения, которое что-то делает, коннектится к базе той же, это просто абсолютно незаметная мелочь.
Миф о раздутости апача, думаю, во многом происходит от mod_php. Когда в каждый процесс апача, отдающий статику, встраивается такая бандура и быстро сжирает всю память, а потом запускаешь все на ngnix+fastcgi и радуешься жизни, осадочек-то остается.
Интересно, но пока только добавил в закладки. Сам использую fastcgi, который запускается по средством супервизора(ИМХО удобно рулить бэкэндами, когда их много)
Я б не доверил вам боевой сервер.
Да, надо ж объяснять почему, а то заминусуют…
Вот так вот, с бухты-барахты, теоретически пораскинув мозгами, даже не попытавшись исследовать проблему, решаем развернуть именно nginx и именно с mod_wsgi. Нету сборки под нашу систему — ничего страшного. Лёгким движением ./configure && make && make install мы превращаем любой дистрибутив в слакварь. Как обновлять сервер, как следить за целостностью пакетов — даже предположений нету. Пофиг, это же Б.О.Е.В.О.Й. сервер, зачем нам эти выдумки?
Рассуждения про очередь и tcp-коннекты… Я даже не знаю, как это комментировать…
> username ALL=NOPASSWD:/bin/kill -HUP *
Вот за эту строчку, я бы выдернул руки.
P.S. Пля, чё за глюки с комментами…
Вот так вот, с бухты-барахты, теоретически пораскинув мозгами, даже не попытавшись исследовать проблему, решаем развернуть именно nginx и именно с mod_wsgi. Нету сборки под нашу систему — ничего страшного. Лёгким движением ./configure && make && make install мы превращаем любой дистрибутив в слакварь. Как обновлять сервер, как следить за целостностью пакетов — даже предположений нету. Пофиг, это же Б.О.Е.В.О.Й. сервер, зачем нам эти выдумки?
Рассуждения про очередь и tcp-коннекты… Я даже не знаю, как это комментировать…
> username ALL=NOPASSWD:/bin/kill -HUP *
Вот за эту строчку, я бы выдернул руки.
P.S. Пля, чё за глюки с комментами…
Есть 2 типа серверов: тестовый и боевой. Боевой не означает, что он работает в стойке яндекса под нагрузкой 100 хитов в секунду. Просто он не тестовый.
Я отлично понимаю, что есть люди, которые лучше меня разбираются в чем угодно. Возможно через неделю я осознаю, что mod_wsgi + nginx вообще не вариант (возможно и нет). Однако же, я достаточно много материала прочел о различных способах запуска web-приложений на питоне и оптимальным мне пока показался именно этот вариант. Но к своему удивлению я не нашел каких-то объемных материалов по этой теме, а проблем, оказалась, уйма.
Насчет строки в sudoers я согласен, сейчас уберу из статьи.
Я отлично понимаю, что есть люди, которые лучше меня разбираются в чем угодно. Возможно через неделю я осознаю, что mod_wsgi + nginx вообще не вариант (возможно и нет). Однако же, я достаточно много материала прочел о различных способах запуска web-приложений на питоне и оптимальным мне пока показался именно этот вариант. Но к своему удивлению я не нашел каких-то объемных материалов по этой теме, а проблем, оказалась, уйма.
Насчет строки в sudoers я согласен, сейчас уберу из статьи.
Официальная страница mod_wsgi, как я понял, здесь. И именно здесь нас постигает главное разочарование — проект не обновлялся больше года.
Официальная страница на code.google.com/p/modwsgi, и проект активно разрабатывается.
UFO just landed and posted this here
Статья полезная, но к Питону как языку программирования имеет весьма косвенное отношение.
Есть же блоги Django, Nginx, Web-разработка. Там она будет более логично смотреться.
Есть же блоги Django, Nginx, Web-разработка. Там она будет более логично смотреться.
Спасибо за статью. Успешно поднял.
Уточню, что для компиляции nginx версии 0.7.60 и выше в файле ngx_http_wsgi_handler.c необходимо
заменить строку:
rc = ngx_http_discard_body(r );
на:
rc = ngx_http_discard_request_body(r );
Перед ней еще комент соответствующий /* XXX not sure */ :)
Уточню, что для компиляции nginx версии 0.7.60 и выше в файле ngx_http_wsgi_handler.c необходимо
заменить строку:
rc = ngx_http_discard_body(r );
на:
rc = ngx_http_discard_request_body(r );
Перед ней еще комент соответствующий /* XXX not sure */ :)
Отличная статья.
Единственное, но: При нескольких приложениях запущенными под разыми server_name на одном сервере вылазил странный глюк, запускалось только то приложение к которому производился запрос, оно и отвечало на остальных именах.
Исправилось переносом include wsgi_params; из location в секцию http.
Единственное, но: При нескольких приложениях запущенными под разыми server_name на одном сервере вылазил странный глюк, запускалось только то приложение к которому производился запрос, оно и отвечало на остальных именах.
Исправилось переносом include wsgi_params; из location в секцию http.
Если кто-то это ещё будет читать как и я сейчас, то пусть знают, что mod_wsgi для nginx таки недавно обновился и был переименован ngx_http_wsgi_module
опечатка " Кто-то должен следать за тем "
Sign up to leave a comment.
Разворачиваем nginx + mod_wsgi на сервере