>Монстра ввиде апача.
apache? не знаю монтстр он или нет, но точно уверен: что mod_wsgi процесс apache-а очень лёгкий.
>В чём проблема запускать uwsgi от разных пользователей?
Раскажите как вы организовали:
1. автоматически старт при перезагрузке системы
2. логирование в /var/log (с logrotate-ом)
У нас на проекте, раньше использовался в различных местах и mod_wsgi и uwsgi, теперь переводится всё на mod_wsgi потому что стабильнее (uwsgi, supervisor у нас переодически отказывали).
>гибкость.
Всё что угодно, от ldap аутентификации, до webdav интеграции. Apache умеет очень много чего, а согласитесь, иметь и uwsgi и apache в production не логично.
> 1. Удобное управление запуском/остановкой/перезапуском нескольких проектов на одном хосте
Удобней работать с нескольикими проектами на одном хосте, когда:
1. каждый из их работает от отдельного пользователя
2. можно перезапускать один не трогая второй
3. каждый проект полностью изолирован (нельзя пользователем одного проекта, читать данные другого проекта).
Мне кажется, данная задача с вашим подходом вызовет некоторые трудности.
Я бы рекомендовал заменить uwsgi на (apache)mod_wsgi — значительно более стабильная и гибкая связка получится.
Интересный факт: LiMo (Linux Mobile) можно считать, что от Samsung-а. Собственно именно после того, как Samsung присоеденился к инициативе Intel и передумал делать Meego. А до этого вполне себе собирался, даже без участия Nokia.
Sorry, не понял ваш комментарий AWS у вас с одной стороны платформа для разработки приложений и облако. С другой стороны AWS (EC2, EBS, VPC) это те сами VPS-ки с возможностью динамического, в том числе автоматического, расширения.
Вы сами не запутались в том, что вы считаете облаком, а что нет?
MySQL является узким местом до того, как будет реализовано нормальное кэширование. После этого, узкими местами становятся другие вещи, вообще это конечно весьма проекто-специфично.
Собствено ничего особенного, едиснтсвенное что, все «удалённые» операции которые не могут быть выполнены на уровне django+mysql (например http запросы к facebook и тд), делаются асинхронно в background-е. Таски при этом передаются через RabbitMQ
«Облака» — это значит, «будет падать», по определению самого облака. Смысл облаков в том, что вы можете взять жменьку серверов, организовать из их отказоустойчевый кластер и выход из строя одной из нод (нескольких) вам будет по ключу.
В проекте, к которому я имею отношение: nginx+uwsgi(python) vs nginx+apache+mod_wsgi(python) при нагрузке в 3.5 млн хитов в сутки/на один сервер не показывают разницы в производительности, всё потрбеление ресурсов всё равно упирается в python-овский интерпритатор.
Причём с одной стороны в мгновенных пиках легко система выходит на 100% загрузки CPU, не переиспользуя при этом память (количество worker-ов держим равным количеству ядер системы).
Я поздравляю uwsgi проект с очередной вехой в развитии, но советую чётко понимать что/как и зачем, если вы меняете один способ работы на другой.
Хотелось бы узнать мнение авторов PVS-Studio, или людей активно использующих различные статические анализаторы года по поводу: «Наскока это полезно, если я *уже* использую valgrind?»
<VirtualHost *:8080>
ServerAdmin admin@example.com
ServerName site1.example.com
ErrorLog /var/log/httpd/site1_error.log
CustomLog /var/log/httpd/site1_access.log common
WSGIScriptAlias / /home/httpd/site1/app/wsgi/django.wsgi
WSGIDaemonProcess user=site1 group=site1 processes=2 threads=1
WSGIProcessGroup site1
WSGIApplicationGroup site1
WSGIPassAuthorization On
apache? не знаю монтстр он или нет, но точно уверен: что mod_wsgi процесс apache-а очень лёгкий.
>В чём проблема запускать uwsgi от разных пользователей?
Раскажите как вы организовали:
1. автоматически старт при перезагрузке системы
2. логирование в /var/log (с logrotate-ом)
У нас на проекте, раньше использовался в различных местах и mod_wsgi и uwsgi, теперь переводится всё на mod_wsgi потому что стабильнее (uwsgi, supervisor у нас переодически отказывали).
>гибкость.
Всё что угодно, от ldap аутентификации, до webdav интеграции. Apache умеет очень много чего, а согласитесь, иметь и uwsgi и apache в production не логично.
Удобней работать с нескольикими проектами на одном хосте, когда:
1. каждый из их работает от отдельного пользователя
2. можно перезапускать один не трогая второй
3. каждый проект полностью изолирован (нельзя пользователем одного проекта, читать данные другого проекта).
Мне кажется, данная задача с вашим подходом вызовет некоторые трудности.
Я бы рекомендовал заменить uwsgi на (apache)mod_wsgi — значительно более стабильная и гибкая связка получится.
bugs.gentoo.org/show_bug.cgi?id=398661
Анонс Tizen произошёл 27 сентября 2011.
С учётом того, что такия слияния не происходи за месяц, я пока наверное останусь при своём мнении.
К LinuxCon Europe уже явно после анонса почти все MeeGo-шники переименовывали свои доклады.
Вы сами не запутались в том, что вы считаете облаком, а что нет?
1. CentOS
2. nginx(стратика + proxy_pass)
3. apache(mod_wsgi, workers=количество ядер CPU)
4. django
5. MySQL
6. RabbitMQ
Собствено ничего особенного, едиснтсвенное что, все «удалённые» операции которые не могут быть выполнены на уровне django+mysql (например http запросы к facebook и тд), делаются асинхронно в background-е. Таски при этом передаются через RabbitMQ
Если вы используете «облака», как vps — ваш fail.
Причём с одной стороны в мгновенных пиках легко система выходит на 100% загрузки CPU, не переиспользуя при этом память (количество worker-ов держим равным количеству ядер системы).
Я поздравляю uwsgi проект с очередной вехой в развитии, но советую чётко понимать что/как и зачем, если вы меняете один способ работы на другой.
en.wikipedia.org/wiki/Elo_rating_system
После этого, lxc и openvz будут их одинаково использовать, возможно предоставляя различные интерфейсы в userspace.
Ведь на самом деле, в ядре нет ни lxc, ни kvm ни т.д. — там есть несколько другие вещи, которые могут использоваться множеством продуктов.