nginx + FastCGI для django приложения---выполняют два веб-сервера или один?
Попробуйте манипулировать свойством visibility вместо display:
function myFunct() {
two.style.visibility = 'visible';
two.style.right = '70%';
}
#two {
visibility: hidden;
display: flex;
...
}
4 ответа
Большинство директив config могут находиться внутри блоков местоположения (т. Е. Они не только глобальные), и это очень часто делается это практика. У вас не должно возникнуть проблем с настройкой, используя только 1 экземпляр nginx.
Одним из замечательных преимуществ этого является то, что вы можете настроить его таким образом, а затем передумать, переключив блок местоположения на бэкэнд-сервер, который не виден внешнему миру.
Итак, сделайте это сейчас на одном сервере, зная, что вы можете подключить бэкэнд-сервер или кластер позже, когда вам понадобится увеличить масштаб.
Я бы сказал, что прокси-сервер django на его собственный сервер действительно вступает в действие только в том случае, если вы используете mod_python, то есть: serve статический с nginx и прокси django для экземпляра apache, выполняющего mod_python. Я с удовольствием запускаю django в lighttpd через fastcgi с тем же lighttpd, обслуживающим и статический контент.
Чтобы ответить на ваш вопрос о размещении сервера nginx перед другим nginx: Нет, обычно для этого нет веских причин. Этот старый совет исходит от Apache, особенно когда mod_python использовался с prefork MPM Apache. В этой настройке каждый экземпляр Django будет запускаться как отдельный процесс внутри контейнера mod_python / Apache, и для этого потребуется много оперативной памяти. Идея состояла в том, чтобы сохранить обслуживание статических файлов вдали от Apache, разместив легкий, управляемый событиями HTTP-сервер, такой как nginx, перед тяжелыми процессами Apache. Это позволило сэкономить оперативную память и повысить производительность. При использовании облегченного сервера, такого как nginx, для всех запросов это не проблема.
nginx хорошо справляется с перезаписью URL, посмотрите в модуль Rewrite.
Ваш вопрос не говорит о том, какая загрузка (соединения / во-вторых) вы ожидаете, или почему вы хотите использовать nginx в первую очередь. Если это для блога на VPS-сервере или аналогичной установки с низкой нагрузкой, то обратите внимание на использование Apache с mod_wsgi в режиме демона. Это имеет производительность и использование ОЗУ очень близко к FastCGI, и mod_wsgi недавно стал официально рекомендованным способом размещения Django, см. http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/
В общем, я бы предложил использовать Apache / mod_wsgi, если это возможно, это стабильная и гибкая комбинация. Убедитесь, что вы не «преждевременно оптимизируете», используя nginx, где Apache + mod_wsgi прекрасно подойдет. Обзор производительности mod_wsgi в режиме демона смотрите: http://code.google.com/p/modwsgi/wiki/PerformanceEstimates
nginx великолепен, но для решения Django nginx ИМХО лучше подходит в качестве балансировщика нагрузки для многих экземпляров Apache или отдельного сервер для статических файлов. Оба этих сценария использования имеют смысл только для больших нагрузок.
Я уверен, что можно настроить все динамическое и статическое содержимое в одном файле конфигурации с одним сервером nginx