Привет.

Не уверен, что данная тема создается в подходящем форуме, но все же.

Есть идея, и вопрос в том, можно ли ее реализовать.

Сайт, на нем документы.
Каждый документ имеет две версии
1. статичный html
2. динамическая страница на php 

Статика - для анонимов, всяких случайных посетителей из поисковиков.
Динамика - для зарегистрированных пользователей, которых меньшинство среди всех посетителей (напр. в день приходит 10000 чел, просмотров 37000, постоянных посетителей около 500, активных зарегистрированных около 200) - содержит всякое интересное для юзеров - голосования за комменты, подсветки всякие и т.д.

Цель - снизить нагрузку на сервер.

Я понимаю, что можно сделать проверку типа

, но быть может есть решения, без вызова php? 

Если да - то как?
Если нет, буду благодарен за любые соображения/ссылки по теме.

опыта реализации подобных механизмов у меня нет, но есть некоторые соображения. прошу отнестись с долей скептицизма.
если "без РНР", значит, у нас не будет информации из сессии о том, залогинен пользователь или нет. Будут только НТТР-заголовки. Среди которых - установленные cookie. Так вот идея в том, чтоб устанавливать зарегистрированным пользователям cookie, при наличии которой затем делать mod_rewrite/SSI/действия с  другими неизвестными мне механизмами, чтоб максимально быстро отдать статику. в РНР коде "динамического варианта" проверку залогиненности придется, конечно, оставить. Но я не думаю, что "хакеров" с вручную установленными cookie будет много.

Собственно, идея skyboy очень не плохая. Я бы только добавил, что можно избавиться от повторной авторизации на PHP, если хранить данные авторизации в memcache. А реализуется все это достаточно просто средствами nginx, алгоритм будет примерно следующий:

1. Приходит запрос в nginx, если он не содержит secret_key, то отдаем пользователю статическую страницу.
2. Шлем запрос в memcache (средствами nginx'а) по имеющемуся secret_key, если ничего не найдено, то отдаем пользователю статическую страницу (или, к примеру, шлем на форму авторизации)
3. Если по secret_key было получено какое-то значение, отправляем запрос на исполнение PHP

Записывать данные в memcache и устанавливать secret_key нужно сразу после аутентификации пользователя.

Для Вордпресса есть плагин кеширования, Supercache plus. Он позволяет сохранять на диск кешированые страницы в формате .html.
Я с ним немного игрался и думаю, что конфигурация для nginx как раз подойдёт.


Если что, в гугле - supercache plus nginx

Это сообщение отредактировал(а) IgorIV - 21.1.2010, 19:36

IgorIV, тогда уж проще proxy cache настроить.

А как распознать гостей и пользователей? Кому из кеша старую, кому новую страницу.

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

Добавлено через 4 минуты и 40 секунд
Больше похоже, что это сделано для apache, т.к. он не имеет таких же гибких возможностей кеширования, как nginx.

??
Это не php-код, это кусок конфига для nginx. Там же идёт проверка кук, проверка метода запроса.

Где вы увидели что бы я писал про PHP код?

Естественно это конфиг nginx, но сделан он, имхо, только для совместимости плагина с nginx'ом, а сам изначально плагин писался, как костыль для apacha. Т.е. все тоже самое в nginx'е "работает из коробки".


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


Если это и является отличием гостей от пользователей, то что по вашему мешает использовать это с кешом?

Это сообщение отредактировал(а) sTa1kEr - 22.1.2010, 09:31

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

С этим не согласен, абсолютно. Плагин писался как костыль модуль для вордпресса. 
Ладно, есть 2 варианта, есть выбор для вопрошавшего.