Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nginx user
Глянул в википедии и ничем энджин от вебсервера отличить не смог :(
Это теория. На практике статический контент сегодня никому не нужен, а
динамический nginx без бэкенда не умеет, грубо говоря.
Это уж очень грубо. php и django через fcgi, tornado через прокси.
Остальное, думаю, тоже можно прикрутить. Зачем нам дополнительная точка
отказа?
А разве для разгрузки мало разных лоадбалэнсеров? Тот же апачи прекрасно
Вы не понимаете.
Апач тратит на одного клиента один процесс. Это тяжело по памяти (не
катастрофически, благодаря copy-on-write, но все же), и по
переключению контекстов.
nginx тратит на одного клиента два сокета и комплект буферов (грубо
говоря), и не вызывает переключения контекста.
Поэтому, если апач нагенерит нам контента, и быстро отдаст его
энджиниксу, и освободит ресурсы, а энджиникс будет со скоростью
клиента контент тому сцеживать - получится экономия, и разгрузка.
И это - основная схема применения nginx.
Лично я (Игорь и Вы видете это иначе) вижу в энджине отличную замену апачи.
Я лично вообще не вижу, зачем менять на что-то апач. он, натурально, прекрасен.
У каждого свои вкусы. Только недавно была тема о том, как одному челу
нужен был сертифицрованный энджин, потомучто апач/iis "не кошерно".
Кстати, не лекарство ли от http://forum.nginx.org/read.php?21,63166 ?
нет, это не связанные вещи. чтобы сделать конфигурябельным хождение по
симлинкам - надо добавить к каждому открытию файла/дикектории один
сискол (не симлинк ли), и одну проверку (если симлинк - можно ли). не,
вру, не один ссискол, а по количеству элементов пути. и цикл,
соответственно, для перебора этих элементов, в купе с парсером строки.
а у нас хайлоад. надо оно нам?..
Для одного проекта - нет, не надо. Для икс маленьких - желательно.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru
|
