На счет веб-сервера apache и хостингов. Да, apache до сих пор предлагают (нечестным хостерам иногда очень легко "раскручивать" клиента на аренду дополнительных мощностей), но если Вы являетесь обладателем apache, то перегруженные файлы htaccess в многочисленных веб-директориях могут опять таки ухудшить производительность вашего веб-ресурса.

Для владельцев VPS и прочих виртуалок + для тех, кто имеет доступ к процессу apache:
Само собой, если речь идет веб-проектах со слабой посещаемостью, такой способ не принесет вреда, но если вы почувствовали "тормоза" (думаю понятно в каком контексте) - самое время поубирать файлы .htaccess в основной конфигурационный файл виртуальных хостов или апача. Т.е. поместить все содержимое в один конфиг, который считывается веб-сервером при запуске индейца. Кроме этого, нужно убрать возможность определений параметров апача по файлам .htaccess (закомментировать параметр) + запретить показ файлов .htaccess. Таким образом веб-сервер теперь не будет тратить время, тратить ресурсы дисковой подсистемы при просмотре директорий.

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

Совет из личного опыта..

Originally Posted by gilas

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

Если вы лично один раз запутались в rewrite-ах, то это не значит что апач плохой. Тем более в обычном форуме vbulletin .htaccess не нужен.
Кстати, распространённая ошибка написать в .htaccess Deny from какой_нибудь_символ_но_не_ip
и вы получаете очень медленный в некоторых случаях вызов преобразования ip в имя хоста. Думаю, где-то оттуда растут ноги этого поверья.

В принципе, эти игры в nginx и fpm добавляют несколько процентов производительности и немножко экономят память, но вообще, не так уж важно каким способом запускать php ( Ну, кроме простого cgi, конечно. Этого следует избегать). Все же видели сколько кода в vbulletin, это ведь не hello world, а сложный скрипт. global.php раскручивается довольно тяжко и подключается на каждый мелкий чих ajax.

Nginx-ом выгодно обслуживать статические файлы. Но зачем еще и отказываться от отработанных годами методов apache и кучи модулей на все случаи жизни ? Если вы собираете проект по кусочкам из разных движков и технологий, то все это пригодится.

Так что очень многим достаточно nginx + обычный apache. Важно, что панель управления хостингом портить не нужно и добавление мелких вспомогательных сайтов можно делать из панели.

Да простят нас модераторы, ибо постепенно тема уходит от прямого назначения (обеспечение безопасности). Справедливо заметить, в этом контексте nginx и apache одинаково безопасны.

Если вы лично один раз запутались в rewrite-ах, то это не значит что апач плохой. Тем более в обычном форуме vbulletin .htaccess не нужен.

Откуда взялось такое утверждение ? mod_rewrite никто не обсуждал, речь шла о механизме htaccess, в который можно помещать не только rewrite правила но и массу других параметров.

Nginx-ом выгодно обслуживать статические файлы. Но зачем еще и отказываться от отработанных годами методов apache и кучи модулей на все случаи жизни ? Если вы собираете проект по кусочкам из разных движков и технологий, то все это пригодится.

Opensource не ограничивает использовать ПО в каких-то отдельных целях. Nginx может обрабатывать статику, а может быть и почтовым прокси. "Apache и куча модулей с отработанными механизмами" - и есть та самая причина, по которой отказываются от индейца , это и есть плохая отличительная черта индейца от остальных веб-серверов. Кроме этого, наше обсуждение идет в контексте php кода, а следовательно можно заметить о вполне работоспособной связке nginx + fcgi и apache + mod_php. В обоих случаях механизм похожий, который как Вы выразились "отработан годами". К тому же от каких модулей индейца Вы не можете отказаться?

Так что очень многим достаточно nginx + обычный apache. Важно, что панель управления хостингом портить не нужно и добавление мелких вспомогательных сайтов можно делать из панели.

Редко пользуюсь сторонними веб-хостингами, но все же видел панель управления из которой можно было настраивать как nginx, так и apache. Ничего порченного в панели не увидел.

По теме - важно заметить, htaccess увеличивает время просмотра веб-директорий индейцем, тратит и без того небольшие ресурсы (потому что остальное уже съедено им). Разговор пошел про htaccess, т.к. топикстартер дал совет защиты с помощью htaccess.

Originally Posted by gilas

По теме - важно заметить, htaccess увеличивает время просмотра веб-директорий индейцем, тратит и без того небольшие ресурсы (потому что остальное уже съедено им). Разговор пошел про htaccess, т.к. топикстартер дал совет защиты с помощью htaccess.

А я считаю, что вы преувеличиваете.
видел как на виртуальном хостинге защищались от ддоса в тысячи строк .htaccess, и никто не выгнал.

Originally Posted by gilas

К тому же от каких модулей индейца Вы не можете отказаться?

А конкретика не так важна. Важно, что на каждую задачу я быстро найду в интернете описание как это сделать в apache и обсуждение проблем.
Где, в конце концов, аналог mod_status в nginx? Он нужен для мониторинга и быстрого распознавания ддос.

Преувеличиваю, если говорить о малой посещаемости и как факт о несущественном ддосе. На нагруженных системах htaccess редко где встретишь (собственноручное выкапывание ямы).

Представляете как ведет себя апач с htaccess ? Упрощенно это выглядит так:

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

Представляете что будет с производительностью системы и скоростью индейца от большого кол-ва запросов, даже пускай от настоящих посетителей, а не от ботов?
Думаю не нужно приводить пример более оптимизированной схемы, ибо и так все просто.

Originally Posted by gilas

Представляете что будет с производительностью системы и скоростью индейца от большого кол-ва запросов, даже пускай от настоящих посетителей, а не от ботов?

зачем представлять, если можно измерить?
вот я взял 10 строк deny from
запустил ab.exe -n 1000 -c 5 http://vb38.local/forum/index.php
и получил без .htaccess

Time taken for tests:   32.797 seconds
Requests per second:    30.49 [#/sec] (mean)
Time per request:       163.984 [ms] (mean)
Time per request:       32.797 [ms] (mean, across all concurrent requests)
Transfer rate:          841.44 [Kbytes/sec] received

с 10 строчками .htaccess

Time taken for tests:   32.469 seconds
Requests per second:    30.80 [#/sec] (mean)
Time per request:       162.344 [ms] (mean)
Time per request:       32.469 [ms] (mean, across all concurrent requests)
Transfer rate:          849.95 [Kbytes/sec] received

то есть, разница есть, но очень маленькая - чуть больше 1%.

отдельно замерим c 1000 строчками

Time taken for tests:   46.500 seconds
Requests per second:    21.51 [#/sec] (mean)
Time per request:       232.500 [ms] (mean)
Time per request:       46.500 [ms] (mean, across all concurrent requests)
Transfer rate:          593.48 [Kbytes/sec] received

И даже с 1000 правил в .htaccess можно попытаться отразить cлабенький ддос. Это не катастрофа.

Я выступаю за фундаментальный подход и за то, чтобы не вводить в замешательство новичков. Для объективных тестов, нужно наполнить содержимое htaccess файла разными параметрами, единственный deny - не показатель. Кроме этого ab слишком "глупая" и с помощью нее нельзя смоделировать настоящую нагрузку, а в данном случае - пользовательский заход со всеми последствиями.
Кроме этого Вы (раз решили тестировать) не показали главного - загрузку дисковой подсистемы + процессора, в моих сообщениях именно этот момент представляет угрозу при использовании htaccess. Нагрузите хотя бы 3 процесса ab (желательно с разных машин) и посмотрите сколько операций IO выполняет апач, какая нагрузка на процессор и что происходит с дисковой подсистемой.

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

Я выступаю за фундаментальный подход и за то, чтобы не вводить в замешательство новичков

Пока я вижу, что ваш "фундаментальный подход" представляет из себя теоретические домыслы, не имеющие практической ценности.
Я согласен что использование .htaccess увеличивает время затрачиваемое на запрос и может вылиться в несколько дополнительных операций с диском, но какую долю эти операции создают?
У меня получилось, что никакую. Покажите ваши тесты, если этот не нравится. Учтите, что я попытаюсь их повторить, поэтому они должны быть достаточно простыми и воспроизводимыми.

Нагрузите хотя бы 3 процесса ab (желательно с разных машин) и посмотрите сколько операций IO выполняет апач, какая нагрузка на процессор и что происходит с дисковой подсистемой.

А почему операции IO должны увеличиться? там всего один файл .htaccess, он закешировался в памяти с диска. И что в этом необычного? И на настоящем сервере закешируется точно так же.
Я там указал 5 потоков в ab.exe.

Originally Posted by netwind

Пока я вижу, что ваш "фундаментальный подход" представляет из себя теоретические домыслы, не имеющие практической ценности.
Я согласен что использование .htaccess увеличивает время затрачиваемое на запрос и может вылиться в несколько дополнительных операций с диском, но какую долю эти операции создают?
У меня получилось, что никакую. Покажите ваши тесты, если этот не нравится. Учтите, что я попытаюсь их повторить, поэтому они должны быть достаточно простыми и воспроизводимыми.

Где же теория? Вы сами только что на практике смогли убедится что разница все же есть. В Вашем случае (назову вашу методику тестирования необъективной и не имеющей ничего общего с реальными условиями) разница составила 1%. В других случаях разница будет 2%, а где-то и все 9%. Веб-проекты у всех разные, содержимое дирректорий тоже, как и посещаемость - у кого-то она 100 человек, а у других 100000.
Представьте себе стартовую страницу посещаемого веб-портала, где при любом корректном запросе (корректный запрос можно сформировать хоть телнетом) будет происходить считывание корневого .htaccess. Представили? Я нет, т.к. не хочется верить в очевидную чепуху - у посещаемого портала в принципе отсутсвует подобный способ загрузки параметров или же у владельца слишком большой парк серверов. Повторить подобные тесты, во всяком случае такие, которые хотите видеть Вы у меня нет возможности. На всех 3-х проектах, где в данный момент у меня есть доступ apache отсутствует как ПО. Везде используется nginx + "гибридные" варианты php.

А почему операции IO должны увеличиться? там всего один файл .htaccess, он закешировался в памяти с диска. И что в этом необычного? И на настоящем сервере закешируется точно так же.
Я там указал 5 потоков в ab.exe.

IO увеличится потому как файл .htaccess нигде не кешируется и при любом (!) обращении считывается индейцем. Отсюда мы неизбежно и без теорий получаем нагрузку на процессор, дисковую подсистему и немного память.
У Вас ведь есть под рукой apache ? Попробуйте поменять содержимое .htaccess файла любой веб-директории и отправить на веб-сервер запрос - мы тут же увидим ваши правки. Теперь снова поменяем содержимое .htaccess на другие параметры - итог, мы опять увидим изменения. Вывод - файл .htaccess считывается веб-сервером при каждом запросе клиента.


ps. ab в 5-10 потоков - дело это не меняет.

Ну так давайте, сделайте свое тестирование. Как это нет возможности? жена не разрешает на ноутбуке программы ставить или что?
Вы вообще никаких данных не приводите. Я даже могу допустить, что я не прав, но для этого нужно повторить ваше тестирование и убедиться, что все действительно так и есть. Даже если мой тест плохой, другого просто нет.

Originally Posted by gilas

IO увеличится потому как файл .htaccess нигде не кешируется и при любом (!) обращении считывается индейцем. Отсюда мы неизбежно и без теорий получаем нагрузку на процессор, дисковую подсистему и немного память

Вот, картиночку прикреплю с данными ввода-вывода:
**тут был скрин, он умер**
Зацените, какой у меня волшебный хостинг дома : его нагружаешь, а он ничего не считывает!
Первый "горб" - запуск ab.exe с .htaccess.
Для сравнения второй "горб" на картинке - запуск utorrent. Вот это приложение действительно считывает кучу файлов.