modrewrite vs REQUEST_URI

[Rifle]

modrewrite vs REQUEST_URI

Вот наткнулся совсем случайно на возможность обрабатывать входящие переменные да и вообще все ссылки внутри самого скрипта, разбивая переменную REQUEST_URI на составляющие. До этого всегда пользовался modrewrite но как мне кажется
обрабатывать в самом скрипте переменные более практичнее и привычнее.

В связи с чем возник вопрос, какой метод использовать более правильно и какой из них будет более быстрым в обработке, может кто сталкивался с подобным вопрос и нашел для себя ответ?

Буду рад выслушать все комментарии по этому вопросу.

 

[Фанат]

приведи пример использования REQUEST_URI вместо modrewrite
а то как-то непонятно

 

[Rifle]

Автор оригинала: *****
приведи пример использования REQUEST_URI вместо modrewrite
а то как-то непонятно

modrewrite

RewriteRule ^([A-Za-z0-9]+)/?$ index.php?content=$1
RewriteRule ^(ru|ua|en)/([A-Za-z0-9]+)?$ index.php?language=$1&content=$2

PHP

  $pieces = explode("/", $_SERVER['REQUEST_URI']);
/* ну и в зависимости от количества анализировать что получили */

-~{}~ 18.06.08 12:05:

Да забыл указать, что все запросы при помощи .htaccess перенаправляются на index.php

 

[StUV]

какой из них будет более быстрым в обработке

роутинг на mod_rewrite однозначно быстрее в несколько раз чем в php-скриптах
при высокой посещаемости рост нагрузки становится ощутимым

-~{}~ 18.06.08 12:14:

зы:
один из основных факторов отказа от полноценного использования ZF - наличие в классах роутера/диспатчера совершенно тупых регулярок - просто лень было это все адаптировать и переопределять с возможностью апдейтов самого фреймворка

 

[Фанат]

Да забыл указать, что все запросы при помощи .htaccess перенаправляются на index.php

жесть. жесть, как она есть.
убийственная поправка. "с помощью .htaccess". Это такой механизм. перенаправления. альтернативный рерайту. ога.

StUV, а ты не забыл, что на проектах, где это имеет значение, уже давно не исползуется тот веб-сервер, модулем для которого является rewrite?
а на других - так ли уж это важно?

 

[Rifle]

Автор оригинала: StUV
роутинг на mod_rewrite однозначно быстрее в несколько раз чем в php-скриптах
при высокой посещаемости рост нагрузки становится ощутимым

-~{}~ 18.06.08 12:14:

зы:
один из основных факторов отказа от полноценного использования ZF - наличие в классах роутера/диспатчера совершенно тупых регулярок - просто лень было это все адаптировать и переопределять с возможностью апдейтов самого фреймворка

Я почему то думал, что modrewrite будет медленнее, спасибо за информацию.

 

[Gas]

Rifle
а C быстрее PHP.
Я вполне верю StUV'у что modrewrit'е быстрее обрабатывает и что в ZF не самый оптимальный алгоритм, но проекты когда это начинает сказываться - частный случай (для большинства).

 

[StUV]

*****
ну.... тормозить пхп-роутингом "тот веб-сервер" (у которого есть свой мод_реврайт) - это тоже не есть гут

+
человек поинтересовался - я ответил
провести тесты самостоятельно на своих скриптах и оценить полезность данной оптимизации в своем конкретном случае он может и сам (и когда-нибудь вероятно до этого доберется)

 

[Фанат]

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

 

[zerkms]

Фaнaт
выпил фанты и тормознул сервер

 

[StUV]

на даже если это и было бы так - ты мерял это "тормозит"?

да
пхп в 1.5 - 3 раза (в среднем) медленнее мод-реврайтов - и на апаче и на нжинксе
при скорости формирования страниц в 10-50 мсек и сложных регулярках апачевый реврайт ничтожен по сравнению с прег_матчами на пхп, которые уже начинают занимать 10-70% от всего выполнения пхп

в усредненном случае большей части запросов - в среднем получается оптимизация сборки страниц из статики 1.5 - 2 раза (если считать от получения запроса веб-сервером до отдачи готового хтмл)

такая вот нехитрая арифметика =)

-~{}~ 18.06.08 15:34:

зы:

А веб-сервер систему не тормозит?

сорри если неточно выразился
речь не о тормозах "системы", а о времени обработки запроса
т.е. при высоких нагрузках повышение этого времени практически пропорционально load average - а это уже сам понимаешь...

 

[HraKK]

StUV

ничтожен по сравнению с прег_матчами на пхп, которые уже начинают занимать 10-70% от всего выполнения пхп

нецензурное слово из 3 букв начинающее на Б заканчивающие на звук - ЛЯ.

можно пример таких регулярок?

 

[StUV]

HraKK
может тебе еще пример страниц, на которых пхп фактически используется только как шаблонизатор ?..
и кроме строковых операций и инклудов в коде нет больше ничего ?
попытайся представить себе такой код, а потом вбей в него регулярку выбирающую из строки запроса с валидацией типов 5-6 переменных и устанавливающей по ЧПУ имя класса обработчика + все необходимые для его инициализации переменные ?
вот тут и будет твое Б... - ЛЯ =)

 

[fixxxer]

про скорость рассуждения смешные, если руки не из зада то разница в пределах погрешности

а выбор должен основываться на архитектуре, если у тебя есть нормальный фронт контроллер (а не switch $_GET['module']) то реврайта может просто не хватить (или будет жутко неудобно)

 

[Rifle]

В моей случае как раз именно"(switch $_GET['module']) =)", хотя парсить в рнр дает больше возможностей на будущее, как мне кажется... т-е можно усложнять логику.

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

 

[StUV]

fixxxer
это не рассуждения
это тупые замеры времени на некотором наборе несложных регулярок
так что...

-~{}~ 18.06.08 18:35:

зы

выбор должен основываться на архитектуре

так и есть
у наших ресурсов есть своя специфика - со свое специфичной физической архитектурой
так что этот момент был действительно очень важным и исследовался очень подробно

-~{}~ 18.06.08 18:45:

да и вообще как-то пофик на самом деле - спор заходит в тупик
ессно, если в коде всякие ОРМы и динамика на базе - эта оптимизация кажется смешной
а если все "тяжелые" вещи крутятся в фоне, а на фронте пхп используется как более гибкий аналог ssi - то такая оптимизация весьма заметна

 

[fixxxer]

с одинарными и двойными кавычками тоже тупые замеры времени и что?

 

[StUV]

долго рассказывать - много не совсем тривиальных архитектурных зависимостей
как-нить за пивом на клоунах объясню в чем там затык

-~{}~ 18.06.08 19:06:

+
будет время - воспроизведу результаты замеров
с апачем я в указанных цифрах уверен
с тех пор перебрались на nginx/fcgi - надо на нем погонять

 

[iamFake]

Автор оригинала: StUV
пхп в 1.5 - 3 раза (в среднем) медленнее мод-реврайтов - и на апаче и на нжинксе
при скорости формирования страниц в 10-50 мсек и сложных регулярках апачевый реврайт ничтожен по сравнению с прег_матчами на пхп, которые уже начинают занимать 10-70% от всего выполнения пхп

незнаю как там в ZF, но у меня, в самописном роутере, регулярок нет... алгоритм чемто схож с _GET и тормозов из за него под нагрузкой нет, ровно как и востребованности в регулярках... а если убрать регистрацию _GET то думаю вообще разници не будет по ресурсам...

 

[fixxxer]

с nginx вообще другой разговор, его location-ы на два порядка гибче чем реврайт