Pull to refresh

Comments 8

То есть заменяем nginx+Apache+mod_php на nginx+uWSGI+«plugins/php»? В этом может смысл есть, а вот при связке nginx+php-fpm какой смысл вводить лишнюю сущность от стороннего вендора? Какие-то убойные фичи?

Может статью поподробнее про сам uwsgi? А то по тэгу три поста, включая этот, а два про джангу.

В проекте, к которому я имею отношение: nginx+uwsgi(python) vs nginx+apache+mod_wsgi(python) при нагрузке в 3.5 млн хитов в сутки/на один сервер не показывают разницы в производительности, всё потрбеление ресурсов всё равно упирается в python-овский интерпритатор.

Причём с одной стороны в мгновенных пиках легко система выходит на 100% загрузки CPU, не переиспользуя при этом память (количество worker-ов держим равным количеству ядер системы).

Я поздравляю uwsgi проект с очередной вехой в развитии, но советую чётко понимать что/как и зачем, если вы меняете один способ работы на другой.
при нагрузке в 3.5 млн хитов в сутки/на один сервер не показывают разницы в производительности, всё потрбеление ресурсов всё равно упирается в python-овский интерпритатор
Вот удивительное дело! Обычно самым узким местом оказывается MySQL, а не python. Не расскажите подробней о связке, которая у вас развернута на сервере (софт)?
MySQL является узким местом до того, как будет реализовано нормальное кэширование. После этого, узкими местами становятся другие вещи, вообще это конечно весьма проекто-специфично.

1. CentOS
2. nginx(стратика + proxy_pass)
3. apache(mod_wsgi, workers=количество ядер CPU)
4. django
5. MySQL
6. RabbitMQ

Собствено ничего особенного, едиснтсвенное что, все «удалённые» операции которые не могут быть выполнены на уровне django+mysql (например http запросы к facebook и тд), делаются асинхронно в background-е. Таски при этом передаются через RabbitMQ
а вот при связке nginx+php-fpm какой смысл вводить лишнюю сущность от стороннего вендора? Какие-то убойные фичи?
Смысл, что php-fpm умеет только php, а uWSGI не только не ограничивается php, но и поддерживает кучу протоколов: uwsgi, http, fastcgi и mongrel2.

Вообщем, я плясал с другой стороны: если есть на сервере «какой-то лёгкий http-сервер» и uWSGI под которым (грамотнее — за которым) работают веб-приложения, на Python или Erlang, а еще нужно поддерживать PHP (ради которого держался, к примеру Apache), то нововведения uWSGI по поддержке php, наряду с поддержкой уже других языков — это очень здорово!
Спасибо, буду иметь в виду. Как-то пробовал делать одновременно рельсы и пхп, но забросил рельсы.
Может статью поподробнее про сам uwsgi? А то по тэгу три поста, включая этот, а два про джангу.
В полной уверенности, что такая статья уже есть! Нужно будет собраться с мыслями и написать, потому как продукт заслуживающий внимания.

PS: Насчет постов про Django — вы абсолтно правы. Такое складывается ощущение, что никто не использует ничего другого. А ведь uWSGI создан для того, что максимально абстрагироваться от специфики работы с тем или иным фреймворком и позволяет «общаться» серверу с любым веб-приложением (точнее WSGI для этого создавался).
Не прошло и суток, уже переведено из альфы в бету.
Sign up to leave a comment.

Articles