Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > PHP: Общие вопросы > Статика для анонимов, динамика для остальных


Автор: abibok 20.1.2010, 21:06
Привет.

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

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

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

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

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

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

if ($is_registered)
{
// ...
}
else
{
// построчно читаем статичный файл и выводим
}

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

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

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

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

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

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

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

# if the requested file exists, return it immediately
    if (-f $request_filename) {
    break;
    }
 
    set $supercache_file '';
    set $supercache_uri $request_uri;
 
    if ($request_method = POST) {
    set $supercache_uri '';
    }
 
    # Using pretty permalinks, so bypass the cache for any query string
    if ($query_string) {
    set $supercache_uri '';
    }
 
    if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
    set $supercache_uri '';
    }
 
    # if we haven't bypassed the cache, specify our supercache file
    if ($supercache_uri ~ ^(.+)$) {
    set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;
    }
 
    # only rewrite to the supercache file if it actually exists
    if (-f $document_root$supercache_file) {
    rewrite ^(.*)$ $supercache_file break;
    }
 
    # all other requests go to Wordpress
    if (!-e $request_filename) {
    rewrite . /index.php last;
    }


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

Автор: sTa1kEr 21.1.2010, 21:40
IgorIV, тогда уж проще http://sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html настроить.

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

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

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

Автор: IgorIV 22.1.2010, 00:39
Цитата(sTa1kEr @  21.1.2010,  23:20 Найти цитируемый пост)
Больше похоже, что это сделано для apache

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

Автор: sTa1kEr 22.1.2010, 07:25
Цитата(IgorIV @  22.1.2010,  01:39 Найти цитируемый пост)
Это не php-код, это кусок конфига для nginx. Там же идёт проверка кук, проверка метода запроса. 

Где вы увидели что бы я писал про PHP код?
Цитата(sTa1kEr @  22.1.2010,  00:20 Найти цитируемый пост)
Так в приведенном вами конфиге

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

Цитата(IgorIV @  22.1.2010,  01:39 Найти цитируемый пост)
проверка метода запроса. 

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

Цитата(IgorIV @  22.1.2010,  01:39 Найти цитируемый пост)
проверка кук

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

Автор: IgorIV 22.1.2010, 17:25
sTa1kEr, ну не умею читать того что не написано. А вот додумывать горазд smile А если еще и мысли не в ту сторону ...
Цитата(sTa1kEr @  22.1.2010,  07:25 Найти цитируемый пост)
 а сам изначально плагин писался, как костыль для apacha. 

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)