Комментарии 38
Казалось бы, причем сдесь способы деплоймента
Даешь хабралюдям скидки! =) Хорошо бы скидки на пиво и обеды в макдональдс.
Интересно, что происходит в районе 2000 запросов?
Сам использую связку nginx+uwsgi, которая так же выигрывает по производительности у fcgi, но помимо всех прочих плюшек, имеет свою изюминку, так как позволяет гибко управлять буферами request/response и доступной памятью для каждого аппликейшн-воркера (что как раз критично для vds). В опциях superfcgi такой возможности не нашел (может плохо искал)
И вот вопрос — поточность воркеров superfcgi предлагает испольование еще и тредов внутри каждого из воркеров. Как это кореллирует с GIL и по сути — форкает ли в итоге каждый тред отдельный подпроцесс питона?
И вот вопрос — поточность воркеров superfcgi предлагает испольование еще и тредов внутри каждого из воркеров. Как это кореллирует с GIL и по сути — форкает ли в итоге каждый тред отдельный подпроцесс питона?
Да мы знаем о uwsgi. Но мне он кажется очень сырым.
C superfcgi разве другая ситуация? Или другие критерии оценки «сырости»? Мне «сырость» наоборот, видится в предложенном вами решении. По крайней мере, я уже вижу uwsgi в gentoo portage. И список фичреквестов в сравнении TODO\Implemented.
А касательно бенчмарков производительности — посмотрите лучше вот это сравнение: nichol.as/benchmark-of-python-web-servers
А касательно бенчмарков производительности — посмотрите лучше вот это сравнение: nichol.as/benchmark-of-python-web-servers
судя из этих тестов gevent рулит
superfcgi тоже сырой, однако своего кода в нем очень мало — сишный модуль взят из официальной fastcgi библиотеки, поэтому довести до ума питонячую часть сложным не представляется.
а сравнивать производительность синхронных библиотеки с tornado, cogen и основанными на libevent — глупо, у них разное применение и принцип работы
а сравнивать производительность синхронных библиотеки с tornado, cogen и основанными на libevent — глупо, у них разное применение и принцип работы
Использую Cherokee + uWSGI (вообше, его можно было и с nginx, но у Cherokee удобная админка, да и особой разницы не вижу)
www.cherokee-project.com/doc/cookbook_uwsgi.html
projects.unbit.it/uwsgi
www.cherokee-project.com/doc/cookbook_uwsgi.html
projects.unbit.it/uwsgi
тоже пользовал cherokee+uwsgi, но из-за того, что виртуалке по ксеном не в bridge, а в route, мне консолью удобнее править конфиги nginx, чем пробрасывать дополнительный порт для cherokee, править текстовой конфиг у которого не доставляет удовольствия ни разу. Итог своих приключений с деплойментом я, собственно, и описал в комменте выше.
Кстати, было бы интересно узнать сравнение со связкой lighttpd + fastcgi.
И tornadoweb (правда я не помню, закончились ли успехом попытки запустить django совместно с ним)
И tornadoweb (правда я не помню, закончились ли успехом попытки запустить django совместно с ним)
Долой такие бенчмарки. Из-за них люди начинают плодить абсолютно неуправляемые связки каких-то bleeding edge сырых технологий, под которые ни мониторинга, ни исследований безопасности, ничего. Профилируйте свои приложения на реальных запросах, оптимизируйте реальные точки нагрузки. А деплоймент должен быть управляемым, гибким, расширяемым.
ulimit -n 10240 (максимальный размер записываемых файлов данным шеллом)
А в какой операционной системе? У меня везде это максимальное число открытых файловых дескрипторов на процесс.
А где лайти, вы что?
Первый раз слышу про superfcgi, интересно, спасибо за наводку.
Но не раскрыта тема конфигурации nginx и apache, кол-во тредов заряженых на обработку запросов и прочее.
Но не раскрыта тема конфигурации nginx и apache, кол-во тредов заряженых на обработку запросов и прочее.
хаха
У вас точно с flup все было правильно настроено? Результаты резко контрастируют с остальными подобными тестами.
Это же статья не о способе развёртывания, а о стеке для продакшн.
Использую nginx/gunicorn — во многих тестах он себя очень хорошо показывает. Заменил им связку nginx/fcgi на очень высоконагруженном проекте и пока не столкнулся ни с одной проблемой. Немного странно, что вы его не протестировали, так как он в последнее время становится все более популярен.
Конфиги-то где, и приложение само?
Что значит «с возрастающей скоростью» — это сколько запросов в секунду в каждый момент времени?
Цифры для flup — странные какие-то. Точно параметры те же были? Опять упираемся в то, что примеров конфигов-то нет.
Говорить-то, по сути, не о чем.
Ну и насчет выводов. Мне кажется непрофессиональным рекомендовать из-за очень небольшой разницы в скорости непопулярный и слабо поддерживаемый (хотя, возможно, и хороший) проект вместо проекта с огромным сообществом, стабильностью и поддержкой. Как будто потенциальные несколько процентов скорости при потенциальной большой нагрузке (которой, уверяю, не будет почти ни у кого и никогда) — это важный критерий для выбора способа деплоя.
Когда что-то настраиваешь питонье, важно понимать:
— разницу между процессами и тредами. Как они влияют на память, как на производительность. Как с этим связан GIL. Какой код вызовет GIL, какой код GIL не вызовет. Что еще может заблокировать выполнение кода, и как это «что» влияет на необходимые параметры (количество процессов и тредов).
— какой способ порождения этих процессов/тредов (заранее, в зависимости от запросов). Что и когда в эти процессы будет загружаться.
— как отдаются данные медленным клиентам
— что будет, если по каким-то причинам выполнение кода в треде/процессе заблокируется совсем
и т.д.
Вот превосходная статья о том, как сделать правильный бенчмарк: blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/
А вот проект, который часть этих бенчмарков реализует: github.com/yaniv-aknin/labour
Простое измерение скорости быстро работающего приложения, даже сделанное правильно, не дает почти ничего. Это измерение непереложимо на практику, по многим причинам. Будет грустно, если разработчики будут принимать решения о выборе способа развертывания на сервере на основе такого рода тестов. Что, похоже, часто и происходит. Достаточно вспомнить волну статей о том, как разворачивать django под tornado (и, похоже, эта дурацкая идея до сих пор витает в воздухе).
Пожалуйста, уважаемые разработчики, не выбирайте способ развертывания на основании такого рода тестов! Если не хотите сильно разбираться, то выбирайте что-нибудь проверенное и надежное, например apache+mod_wsgi для бэкенда и nginx перед ними. Если хотите — разбирайтесь, как что работает, и уже тогда думайте уже своей головой, имея в виду детали проекта.
Что значит «с возрастающей скоростью» — это сколько запросов в секунду в каждый момент времени?
Цифры для flup — странные какие-то. Точно параметры те же были? Опять упираемся в то, что примеров конфигов-то нет.
Говорить-то, по сути, не о чем.
Ну и насчет выводов. Мне кажется непрофессиональным рекомендовать из-за очень небольшой разницы в скорости непопулярный и слабо поддерживаемый (хотя, возможно, и хороший) проект вместо проекта с огромным сообществом, стабильностью и поддержкой. Как будто потенциальные несколько процентов скорости при потенциальной большой нагрузке (которой, уверяю, не будет почти ни у кого и никогда) — это важный критерий для выбора способа деплоя.
Когда что-то настраиваешь питонье, важно понимать:
— разницу между процессами и тредами. Как они влияют на память, как на производительность. Как с этим связан GIL. Какой код вызовет GIL, какой код GIL не вызовет. Что еще может заблокировать выполнение кода, и как это «что» влияет на необходимые параметры (количество процессов и тредов).
— какой способ порождения этих процессов/тредов (заранее, в зависимости от запросов). Что и когда в эти процессы будет загружаться.
— как отдаются данные медленным клиентам
— что будет, если по каким-то причинам выполнение кода в треде/процессе заблокируется совсем
и т.д.
Вот превосходная статья о том, как сделать правильный бенчмарк: blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/
А вот проект, который часть этих бенчмарков реализует: github.com/yaniv-aknin/labour
Простое измерение скорости быстро работающего приложения, даже сделанное правильно, не дает почти ничего. Это измерение непереложимо на практику, по многим причинам. Будет грустно, если разработчики будут принимать решения о выборе способа развертывания на сервере на основе такого рода тестов. Что, похоже, часто и происходит. Достаточно вспомнить волну статей о том, как разворачивать django под tornado (и, похоже, эта дурацкая идея до сих пор витает в воздухе).
Пожалуйста, уважаемые разработчики, не выбирайте способ развертывания на основании такого рода тестов! Если не хотите сильно разбираться, то выбирайте что-нибудь проверенное и надежное, например apache+mod_wsgi для бэкенда и nginx перед ними. Если хотите — разбирайтесь, как что работает, и уже тогда думайте уже своей головой, имея в виду детали проекта.
gunicorn + nginx же
А что это за дедок? Это под себя разработали такого?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дедок рекомендует или сравниваем различные способы деплоймента Django-приложений