On 11.08.2011 1:08, Oleksandr V. Typlyns'kyi wrote:

>>>> но в случае mass virtual hosting`а - администратор вынужден давать
>>>> пользователям .htaccess иначе его достанут запросами на изменение
>>>> конфигурации и apache только тем и будет заниматься что релоад
>>>> конфигурации после того как администратор внесет вручную
>>>> в основной конфиг запрашиваемые пользователями изменения.

>>> В случае с .htaccess apache делает(а то и циклически) "релоад конфигурации" на каждый запрос.

>> Нет.

>> service httpd reload - это достаточно дорогое удовольствие,
>> потому что при этом перезапускаются worker-процессы апача.

> Геннадий, я имел ввиду следующее:
> "However, putting this configuration in your server configuration file will result in less of a performance hit, as the configuration is loaded once when Apache starts, rather than every time a file is requested"
> Вас беспокоит расход ресурсов на reload, но целиком устраивает процессинг .htaccess на каждый запрос?

"процессинг .htaccess на каждый запрос" - это самый оптимальный вариант.

расход ресурсов на "процессинг .htaccess" гораздо меньше чем на релоад.

> А ведь запросов, по сравнению с изменениями конфигурации, в очень много раз больше.

все эти файлы .htaccess которые апач будет открывать при обработке
запросов клиентов и так уже будут находиться в файловом кеше
операционной системы - их не надо будет считывать с жесткого диска
сервера. Какие именно ресурсы Вы пытаетесь экономить, предлагая вместо
.htaccess файлов писать весь конфиг в httpd.conf и делая частые релоады?

чтобы было понятно о чем разговор: mass virtual hosting - это когда
на сервере много разных клиентов, которые имеют доступ к своим файлам
по ssh/ftp и которые достаточно часто что-то там устанавливают,
обновляют, изменяют, редактируют и т.п. в день будет происходить
при этом от нескольких десятков до нескольких сотен и даже тысяч
релоадов httpd из-за изменений единственного конфига httpd.conf

не уверен, что такие частые релоады httpd будут более оптимальным
вариантом, чем использование .htaccess из файлового кеша сервера.

>> старые worker-процессы nginx получают сигнал QUIT на плавное завершение,
>> которое может занять от нескольких секунд до нескольких часов и даже
>> дней, в зависимости от того, насколько большие файлы отдаются клиенту
>> и насколько медленно он их скачивает с веб-сервера.

> Для apache можно задать GracefulShutdownTimeout:
> http://httpd.apache.org/docs/2.2/mod/mpm_common.html#gracefulshutdowntimeout

это приведет к тому, что часть клиентов получат обрыв связи
и недокачанный файл. в результате - есть риск получить претензии
о том, что "до 26 апреля сего года не было ни единого разрыва".

в общем - совсем не убедительно что полный отказ от использования
.htaccess файлов принесет пользу а не вред. учитывая даже только
сколько времени надо будет потратить на объяснение клиентам,
почему апач игнорирует все их настройки в файлах .htaccess

особенно, если они закрыли доступ к какому-то каталогу
через .htaccess а потом вдруг оказалось, что эти файлы
доступны всем желающим через сеть интернет.

"Такой хоккей нам не нужен!" (с) Николай Озеров
http://sport.rambler.ru/news/10347/11272212.html

>>> Хотя людям любящим .htaccess достаточно и просто apache без nginx.

>> http://lurkmore.ru/ЧСВ ?

> Нет - ЧНЯЧ.

"Хотя людям любящим .htaccess достаточно и просто apache без nginx"

- это разве хоть чем-то похоже на ЧНЯЧ ???

> Документация apache говорит что .htaccess - плохо для производительности.

частые релоады апача для производительности будут еще хуже.

> Любишь .htaccess - не любишь производительность.

"любить файлы" - это в каком смысле? не совсем понимаю.

> Не нужна производительность - зачем же тогда nginx?

попробуйте сделать mass virtual hosting без поддержки .htaccess файлов,
и Вам тогда сразу станут очевидными Все Ваши заблуждения на этот счет.

> У подавляющего большинства потребителей shared hosting нет огромных файлов.

а если есть? файлы от нескольких сотен мегабайт до нескольких гигабайт.

> А посему их, как уже писал Максим Дунин, при необходимости .htaccess можно полностью проксировать.

приведите пожалуйста фрагмент конфига nginx,
как Вы себе это проксирование представляете.

> При этом через разные location для разных типов файлов можно задать нужные параметры буферизации.

параметры двойной буферизации файлов на жесткий диск сервера?
это снизит нагрузку backend-сервера, но увеличит дисковый i/o.

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru