nginx Compatibility

Делаем WordPress дружелюбнее к nginx

Описание

Плагин предназначен для решения двух проблем:

  1. Когда обнаруживает, что используется SAPI, код перенаправления, передаваемый в wp_redirect(), игнорируется. Таким образом, все перенаправления с кодом 301 тихо превращаются в перенаправления с кодом 302, что не очень хорошо для SEO.
    Если работает под управлением , плагин переопределяет функцию wp_redirect(), что позволяет использовать коды перенаправления.
  2. Если считает, что (модуль Apache, отвечающий за переписывание URL’ов — используется для красивых постоянных ссылок) не загружен (а не использует модули и API Apache), он предлагает использовать постоянные ссылки в формате PATHINFO (Настройки » Постоянные ссылки). Такие ссылки не очень красивы, но всё же лучше, чем ничего.
    Тем не менее, умеет переписывать URL’ы, но не может об этом сказать . За него это делает плагин, заставляя думать, что всё-таки загружен, и можно использовать красивые пермалинки.

Установка

  1. Загрузите каталог -compatibility в /wp-content/plugins/
  2. Активируйте плагин в панели управления
  3. Это всё :-) Никакой настройки не требуется, плагин сам обо всём позаботится

Замечания по конфигурации

Хотя данный плагин и позволяет использовать красивые постоянные ссылки, для этого требуются специальные правила в конфигурации виртуального хоста.

Для версии 0.7.32 и старше могут использоваться такие правила (приведены только релевантные блоки):

[-]
View Code nginx configuration
server {
    server_name mysite.com www.mysite.com;

    root /path/to/blog;

    index index.php;

    location / {
        try_files $uri $uri/ @wordpress;
    }

    location @wordpress {
        fastcgi_pass ...;
        fastcgi_param SCRIPT_FILENAME /path/to/blog/index.php;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_NAME /index.php;
    }

    location ~ \.php$ {
        try_files $uri @wordpress;
        fastcgi_index index.php;
        fastcgi_pass ...;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }
}

Для младших версий конфигурация виртуального хоста будет несколько другой:

[-]
View Code nginx configuration
server {
    server_name mysite.com www.mysite.com;

    root /path/to/blog;

    index index.php;

    location / {
        log_not_found off;
        error_page 404 = @wordpress;
    }

    location @wordpress {
        fastcgi_pass ...;
        fastcgi_param SCRIPT_FILENAME /path/to/blog/index.php;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_NAME /index.php;
    }

    location ~ \.php$ {
        if (!-e $request_filename) {
            rewrite ^(.+)$ /index.php break;
            break;
        }

        fastcgi_index index.php;
        fastcgi_pass ...;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }
}

Замените /path/to/blog путём к блогу, в fastcgi_pass задайте адрес сервера -cgi (обычно это 127.0.0.1:9000).
Для старых версий , возможно, придётся изменить строку rewrite ^(.+)$ /index.php break;, если блог расположен не в корне сайта.

Файл fastcgi_params (в Debian он обычно в /etc/, в других системах он может располагаться в другом месте — используйте правильный путь в директиве include!) выглядит примерно так (скорее всего, он идёт в стандартной поставке ):

[-]
View Code nginx configuration
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

fastcgi_buffer_size 32k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Есть вопросы по конфигурации — пишите.

Часто задаваемые вопросы

Вопросов пока нет, ответов тоже. Задавайте.

Замечания

GoPHP5! Плагину для работы требуется  5.  4 не поддерживается разработчиками, у меня тоже нет желания его поддерживать. Тем более, что шестая версия на носу.

Домашняя страница плагина на wordpress.org.

Добавить в закладки

Связанные записи

Автор: Vladimir; метки: FastCGI, mod_rewrite, nginx, PHP, WordPress, плагин

RSS Комментарии к статье «nginx Compatibility» (53)  »

  1. Alex
    Март 1, 2010 в 14:30

    Именно так. Спасибо!!! (ушёл посыпать голову пеплом)

  2. Ashes in the Fall « Shattered Crystalline Matrix
    Март 5, 2010 в 22:13

    [...] nginx Compatibility (PHP5): for better operation behind nginx. [...]

  3. Антон
    Апрель 6, 2010 в 02:45

    Владимир, рассчитываю на Вашу компетентную помощь. На хостинге два сайта, настроена связка nginx+php+fast-cgi (один – на WordPress’е, и Ваши рекомендации и плагин уже помогли с этим).
    Сайты с небольшой посещаемостью (несколько десятков человек и 100-200 страниц за сутки), и имеет место эффект своего рода холодного старта: при открытии сайта он грузится дольше, и дольше генерируется страница. Если сразу перейти на другую страницу – быстрее и отдача, и время генерации. (по вордпрессу 0.300-0.500 против двух и больше секунд, вся загрузка – порядка 3 сек против 6-7 секунд и больше после паузы). Стоит остаться на странице на минуту-полторы – всё сначала (я так понимаю – если кто-то ещё в этот момент на сайте не совершает переходы).
    То есть новые посетители и внимательные читатели получают работу сайта зримо медленнее возможной – а ресурсы, наоборот, свободны. И если, скажем, подключение eaccelerator’а и сокращает время генерации на 100-200 мс, то на фоне описанной проблемы такие вещи уже мало радуют.
    Заходя по ssh, я вижу, конечно, запущенные процессы nginx’а и php. Ресурсы, по данным панели хостинга, используются чуть больше чем наполовину по памяти, по процессам – 25-30%. Эффект не всегда резко выражен, возможно – днем сильнее, так что грешу даже на хитрости хостера (это ру-центр, 201 тариф). Можно ли с помощью настроек конфига nginx или php повлиять на эту проблему? Если да – то как, или хотя бы куда копать? Пока нашёл только диковатую рекомендацию запрашивать свою же страницу по крону раз в несколько минут.

    • Vladimir
      Апрель 6, 2010 в 13:04

      А точно проблема не в медленных запросах к базе? Просто если Вы используете кэш, то причина холодного старта как раз понятна. Можно попробовать поставить SQLMon и посмотреть на запросы, возможно, что проблема там.

      А еще в Вашем тарифе есть ограничение на число одновременных соединений с MySQL (16). Получается, что в конкретный момент времени к сайту могут обращаться не более 16 пользователей (с учетом всяких wp-cron/AJAX возможно, что и меньше), последующие соединения будут ставиться в очередь. Это тоже может быть причиной тормозов.

      • Антон
        Апрель 6, 2010 в 16:58

        Похоже, база здесь не ограничивает. Да, кэш использую, и попробовал мониторить, там есть неоптимальные, видимо, запросы (красный цвет). Но когда поймал время генерации 2.217, то при этом SQL Monitor: Total 9 queries, time taken: 0.04014.
        Обновил страницу, выждав пару минут – опять две с копейками секунды (8 queries). Сразу F5 – получил 0.346, а результаты по базе – близкие (и те же 8 запросов), хотя и чуть быстрее.

        • Vladimir
          Апрель 6, 2010 в 18:42

          Антон, обновите плагин (SQLMon). Потом обратите внимание, сколько времени занимает запрос CONNECT user:password@host/db (он, вероятно, будет самым первым).

          • Антон
            Апрель 6, 2010 в 22:31

            Да – первая строка, вот такие три результата для трёх последовательных запросов одной страницы: 0.0152 0.06547 0.00781. Время генерации страницы (в том же порядке):1.857 0.878 0.371, вроде бы нет корреляции.

  4. Wordpress Caching Comparision – W3 Total Cache vs. WP Super Cache vs. WP Cache | RogRandom.com
    Июнь 11, 2010 в 20:49

    [...] 2.9.2, standard Kubrick theme, nginx Compatibility plug-in [...]

« Назад

Оставить комментарий к записи «nginx Compatibility»

Вы должны быть авторизованы, чтобы иметь возможность оставить комментарий.

Подписаться, не комментируя