Я использую nginx + fastcgi (manage.py runfcgi ...) для некоторых проектов Django. Многие люди предлагают использовать nginx + gunicorn. В чем преимущество использования gunicorn вместо использования сервера Django fastcgi?В чем заключается недостаток использования сервера fastcgi от Django
Я просто сказать, почему вы должны использовать WSGI подобные серверы :) но если вы чувствуете себя комфортно с помощью FCGI - просто использовать его
Короткий ответ: WSGI (как протокол) прохладно, потому что its native
Или если «вам нужно идти глубже» (c)
Следующий вопрос «FastCGI против WSGI-подобных серверов?»
Некоторые ответы здесь:
О gunicorn, uWSGI и Чероки, Nginx. Не смешивайте их!
nginx - это веб-сервер, который может обрабатывать HTTP-запросы и может отправлять его на сервер WSGI. (Но в первую очередь это чрезвычайно быстро для обработки статического содержимого.) И сервер WSGI обрабатывает приложение django.
О cherokee, я думаю, что он выполняет те же задачи, что и nginx, но я не работаю с ним.
И gunicorn, uWSGI являются WSGI бэкенд которые идут потоки с Джанго приложения и сделать many other tasks
И хммм, gunicorn say что
Будучи сервер, который работает только на Unix-подобных платформах, единорог сильно привязанный к философии Unix, чтобы сделать одно и (надеюсь) сделать это хорошо. Несмотря на использование HTTP, единорог является строго сервером прикладных программ для работы с Rack-based Ruby-приложениями.
Я тренируюсь для моего приложения Джанго Nginx (последний стабильный от nginx.org РЕПО) + uWSGI (из конюшен Debian) - работает отлично :)
отредактирован 18.05.2012
Ссылка на 2010 тему с сравнением fcgi gunicorn uWSGI
FCGI (резьбовой) 640 г/с
FCGI (PreFork 4 процессоров) 240 Р/с (*)
gunicorn (2 рабочие) 1100 г/с
gunicorn (5 рабочих) 1300 г/с
gunicorn (10 WO rkers) 1200 г/с (?!?)
uwsgi (2 рабочие) 1800 г/с
uwsgi (5 рабочих) 2100 г/с
uwsgi (10 рабочих) 2300 г/с
(* это сделало мой компьютер исключительно вялой, как CPU, когда через крышу)
«FastCGI против WSGI» - неправильный вопрос. FastCGI - это сетевой протокол, а WSGI - соглашение о вызове Python. [flup] (http://trac.saddi.com/flup) имеет шлюз FastCGI-to-WSGI. Команда 'runfcgi' Django фактически основана на flup и поэтому использует WSGI. Лучший вопрос - это всплеск против uwsgi или flup против gunicorn. –
Вы правы в отношении «FastCGI против WSGI». Измените тему на WSGI-like. И я думаю, что битва «flup vs. uwsgi vs. gunicorn» выиграет uWSGI. В ближайшее время я попытаюсь представить некоторые доказательства. – nk9
Ну, кто «выигрывает», зависит от ваших критериев. У меня есть десяток сайтов с низким трафиком, поэтому простота обслуживания и использования памяти важнее для меня *, чем сырая производительность (во всяком случае, в которой все чаще используются запросы к базе данных). Uwsgi не упакован в debian squeeze (текущий стабильный) , в то время как взрыв и стрельба. –
Как b1- говорит, WSGI является родным (посмотрите на this post).
Кроме того, у this post есть аналогичный вопрос.
С моей личной точки зрения, некоторое время назад я использовал Nginx + uwsg in vhost mode для запуска различных проектов на своем сервере.
... и uWSGI имеет режим зергов^_ ^ – nk9
Также посмотрите на uwsgi. –
FastCGI Устарел с версии 1.7: поддержка FastCGI устарела и будет удалена в Django 1.9., Поэтому я предлагаю перейти на uWSGI. – ashish