>> Глянул в википедии и ничем энджин от вебсервера отличить не смог :(
>>
> Это теория. На практике статический контент сегодня никому не нужен, а
> динамический 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@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru