Ars Longa, Vita Brevis » FastCGI

Qt, libfcgi и многопоточность

Vladimir — Sun, 08 Jan 2012 17:31:00 +0000

Предотвращение блокирования событий при использовании libfcgi в многопоточном режиме

Для создания приложений FastCGI на C/C++ есть библиотека libfcgi. Не буду вдаваться в дискуссию, зачем нужны приложения FastCGI на C/C++/подставить нужный язык, когда Python/PHP/Perl/подставить нужное гораздо удобнее. Отмечу лишь, что по работе понадобилось написать FastCGI-приложение на Qt (в основном из-за наличия нескольких высокопроизводительных библиотек, написанных на Qt, но не суть).

Строго говоря, libfcgi, хотя и является официальной библиотекой от создателей протокола, не лучший вариант для поддержки FastCGI — API, предоставляемое библиотекой, сильно ограничено (в плане функциональности) и недостаточно гибко.

Грубо говоря, приложение, использующее libfcgi, может работать в двух режимах:

Последовательная обработка запросов: приложение получило запрос, обработало его, отправило результат, получило следующий запрос. Схема хороша, если обработка запроса тривиальна и/или не занимает много времени. Скорее всего, под большой нагрузкой масштабируется плохо, ибо чем длиннее очередь запросов, тем дольши придётся ждать клиенту.
Многопоточная обработка запросов: приложение создаёт определённое количество потоков, каждый из которых будет обрабатывать свой запрос. При средних нагрузках эта схема работает лучше (если один поток занят, свободный поток займётся выполнением запроса). Но в предельном случае (когда все потоки заняты) имеем те же проблемы, что и в первом варианте. Схему можно немного изменить, создавая потоки по мере необходимости, но всё равно плодить потоки до бесконечности нельзя.

Использование потоков не всегда уместно/хорошо: многопоточные программы, как правило, сложнее для разработки и отладки; кроме того, потоки потребляют системные ресурсы (например, память для стека) и при большом количестве потоков эти издержки могут быть существенными (например, для Linux/IA-32 размер стека для потока по умолчанию составляет 2 мегабайта).

К сожалению, при использовании libfcgi отказаться от потоков очень трудно — дело в том, что библиотека использует блокирующие операции при работе с сокетами.

В общем случае алгоритм работы с libfcgi следующий:

/* Инициализация */
FCGX_Init();
int socket = FCGX_OpenSocket(":9001", 256);

/* ... */

// Собственно работа
while (true) {
FCGX_Request* req = new FCGX_Request;
FCGX_InitRequest(req, socket, 0);

int rc = FCGX_Accept_r(req);
if (rc >= 0) {
/* Здесь создаём и запускаем поток, отвечающий за обработку запроса */
}
}

В случае с Qt и использованием рабочего цикла внутри основной программы имеется неприятный подводный камень: из-за того, что FCGX_Accept_r() использует блокирующие вызовы при работе с сокетом, основная программа может очень долго не увидеть сообщения, посылаемые, например, потоком.

Поэтому перед вызовом FCGX_Accept_r() имеет смысл проверять, имеются ли запросы на соединение.
Решение в лоб:

#include
#include

/* ... */

int rc;
do {
QCoreApplication::processEvents();
struct timeval tv = { 0, 500 };
fd_set r;
FD_ZERO(&r);
FD_SET(socket, &r);

rc = ::select(socket+1, &r, 0, 0, &tv);
} while (!rc);

FCGX_Request* req = new FCGX_Request;
FCGX_InitRequest(req, socket, 0);
int sock = FCGX_Accept_r(req);
/* ... */

Но более корректно будет использовать QSocketNotifier:

// core.h
#include

class QSocketNotifier;

class Core : public QObject {
Q_OBJECT
public:
explicit Core(QObject *parent = 0);
void run(void);

private:
QSocketNotifier* m_notifier;

private slots:
void connectionPending(int socket);
};

// core.cpp

Core::Core(QObject *parent) : QObject(parent), m_notifier(0)
{
FCGX_Init();
int sock = FCGX_OpenSocket(":9001", 256);
this->m_notifier = new QSocketNotifier(sock, QSocketNotifier::Read);
QObject::connect(this->m_notifier, SIGNAL(activated(int)), this, SLOT(connectionPending(int)));
}

void Core::connectionPending(int socket)
{
QSocketNotifier* notifier = qobject_cast<QSocketNotifier*>(this->sender());
Q_CHECK_PTR(notifier);

notifier->setEnabled(false);

FCGX_Request* req = new FCGX_Request;
FCGX_InitRequest(req, socket, 0);
int s = FCGX_Accept_r(req);
if (s >= 0) {
/* Здесь создаём и запускаем поток */
}

notifier->setEnabled(true);
}

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

#include
#include
#include
#include

class Queue {
public:
void addToQueue(FCGX_Request* r, bool broadcast = false)
{
QMutexLocker locker(&this->mx);
this->queue.enqueue(r);
if (broadcast) {
this->cv.wakeAll();
}
else {
this->cv.wakeOne();
}
}

FCGX_Request* getFromQueue(void)
{
this->mx.lock();
while (this->queue.isEmpty()) {
this->cv.wait(&this->mx);
}

FCGX_Request* result = this->queue.dequeue();
this->mx.unlock();
return result;
}
private:
QMutex mx;
QWaitCondition cv;
QQueue<FCGX_Request*> queue;
};

Но это уже совсем другая история.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

WordPress: кэширование средствами nginx

Vladimir — Fri, 10 Dec 2010 12:08:15 +0000

Уменьшение потребления ресурсов во много раз

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

Метод основан на использовании кэша FastCGI web-сервера nginx.

Идея состоит в генерации статических страниц и отдачи их пользователям, не имеющим cookie комментатора. Зарегистрированным пользователям, а также комментаторам всегда отдаётся свежая страница. Так как читателей, ни разу не оставлявших комментарий, как правило, гораздо больше, чем комментаторов, то подобный использование кэша позволяет значительно снизить нагрузку на WordPress/PHP. Знакомые с принципом работы WP Super Cache заметят, что WPSC использует тот же принцип работы.

В чем же преимущество перекладывания работы на Web-сервер (nginx)?

PHP — интерпретируемый язык. Как следствие, аналогичный код на компилируемом языке будет во много раз быстрее.
WordPress во многом bloatware От момента начала загрузки страницы до окончания выполнения стадии init выполняется очень много «лишнего» кода.
В зависимости от нагрузки на сервер от запроса страницы до выполнения PHP-кода может пройти некоторое время: всё зависит от загруженности PHP (если все дочерние процессы PHP заняты обработкой запроса, новому запросу придётся ждать освобождения одного из процессов. Если за приемлемое время ни один процесс не освободился, пользователь видит сообщение о печально знаменитой ошибке 504).
Когда обслуживанием кэша занимается web-сервер, шансы на возникновение подобной ситуации

Теперь переходим от теории к практике.

fastcgi_cache_path /var/lib/nginx/myblog levels=2 keys_zone=myblog:10m max_size=512m inactive=20m;
server {
server_name example.com;
root /path/to/blog;
index index.php;
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
set $do_not_cache 1;
}
fastcgi_cache_bypass $do_not_cache;
fastcgi_no_cache $do_not_cache;
fastcgi_pass_header Cookie;
fastcgi_cache myblog;
fastcgi_cache_key $request_method|$host|$request_uri;
fastcgi_cache_valid 301 8h;
fastcgi_cache_valid 404 1h;
fastcgi_cache_valid 200 15m;
if ($http_user_agent !~ FeedBurner) {
# Здесь идут перенаправления для FeedBurner
}
error_page 404 = @wordpress;
log_not_found off;
location ^~ /files/ {
rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
}
location ~ ^/(wp-admin/.*\.php|wp-login\.php|wp-register\.php|(feed|comment/feed)(/.*)?)$ {
try_files $uri @wordpress;
set $do_not_cache 1;
fastcgi_cache_bypass 1;
fastcgi_no_cache 1;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_index index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location @wordpress {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME /index.php;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_index index.php;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
try_files $uri @wordpress;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ^~ /blogs.dir/ {
internal;
root /path/to/blog/wp-content/;
}
}

Документация по использованию FastCGI в nginx приведена здесь, поэтому я не буду подробно останавливаться на том, что конкретно каждая директива делает.

Основная магия происходит в строка 8—10: здесь определяются условия, при которых отдаётся свежая страница. В данном случае проверяется наличие авторизационных cookie и cookie комментатора. Важно, чтобы в случае отказа от кэширования переменная $do_not_cache устанавливалась в 1.

Строка 16 задаёт ключ, по которому страница доступна в кэше. В ключе присутствует $request_method, чтобы различать запросы GET и HEAD (для HEAD данные не возвращаются, только заголовки).

Строки 17—19 задают время жизни кэша в зависимости от кода ответа. Чем больше время жизни, тем реже будет обновляться информация для незарегистрированных пользователей.

В строке 32 задаётся маска для страниц, которые не должны кэшироваться (например, админка, страницы логина и регистрации, фиды).

Так как содержимое страницы может отличаться в зависимости от cookie пользователя, в строках 49 и 59 для закэшированных страниц принудительно выставляется заголовок Vary: Cache. Если используются другие правила (например, фильтрация по User-Agent), нужно добавлять соответствующее правило.

Строки 21—23: подробнее описано в статье «Перенаправление RSS в WordPress на FeedBurner для nginx»

Строки 28—30, 63—66 подробнее описаны в статье «WordPress MultiSite, nginx и X-Accel-Redirect»

Вроде бы ничего не забыл. Теперь о том, какую производительность мы получаем:

$ ab -n 10000 -c 100 http://blog.sjinks.pro/
Server Software: nginx
Server Hostname: blog.sjinks.pro
Server Port: 80

Document Path: /
Document Length: 50294 bytes

Concurrency Level: 100
Time taken for tests: 46.925 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 504940000 bytes
HTML transferred: 502940000 bytes
Requests per second: 213.10 [#/sec] (mean)
Time per request: 469.254 [ms] (mean)
Time per request: 4.693 [ms] (mean, across all concurrent requests)
Transfer rate: 10508.28 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 16 94 76.9 94 3125
Processing: 118 373 81.7 360 1334
Waiting: 17 69 38.5 57 422
Total: 156 467 105.0 445 3535

Percentage of the requests served within a certain time (ms)
50% 445
66% 454
75% 471
80% 494
90% 541
95% 589
98% 655
99% 768
100% 3535 (longest request)

Сервер зафлудили 10,000 запросами в 100 параллельных потоков. Сервер выдал практически полгигабайта за 47 секунд; в среднем сервер обрабатывал 213 запросов в секунду, при этом 99% запросов были обработаны за 768 мс (при том, что на сервере несколько сайтов в Alexa Top 100,000)! Нагрузка на сервер была минимальной (изменений Load Average замечено не было).

UPDATE: есть один небольшой нюанс: CAPTCHA. Если вы их используете, убедитесь, что они работают. Дело в том, что страница со статьёй будет отдаваться непосредственно из кэша nginx, PHP загружаться не будет. Поэтому если CAPTCHA полагается на использование сессии, она может работать неправильно. Здесь всё зависит от используемого плагина.

WordPress MultiSite, nginx и X-Accel-Redirect

Vladimir — Sat, 04 Dec 2010 09:25:34 +0000

Ускорение загрузки файлов с дочерних блогов

Одна из основных особенностей WordPress 3.0 — поддержка конфигурации MultiSite.

При использовании FastCGI с WordPress MultiSite может выявиться одно слабое место: загруженные файлы (которые uploads) дочерних блогов отдаются PHP-скриптом (wp-includes/ms-files.php). Если количество процессов FastCGI небольшое, а загружаемые файлы большие и при этом имеется медленные клиенты, проблемы с производительностью гарантированы: дело в том, что один процесс FastCGI в один момент времени может обслуживать только одного клиента. Если запущено 5 процессов php-cgi, и имеется пять медленных клиентов, качающих файлы, все остальные клиенты будут ждать освобождения процессов PHP. Если клиенты медленные, а файлы большие, ждущие клиенты будут получать ошибку 504.

К счастью, при использовании nginx проблема легко решается.

nginx поддерживает метод, при котором приложение (в данном случае WordPress) может переложить ответственность за отдачу файла клиенту на nginx. Это достигается путём использования специального заголовка, X-Accel-Redirect (интересующимся подробностями рекомендую статью Алексея Ковырина). WordPress полностью поддерживает данный метод. Но по умолчанию данный метод не используется, так как сначала нужно правильно настроить nginx.

Базовая настройка nginx для использования с WordPress приведена в соответствующей статье, здесь же мы рассмотрим изменения, необходимые для поддержки multisite.

Загруженные файлы дочерних блогов располагаются в каталогах /wp-content/blog.dir//; WordPress же для отдачи файлов использует URL вида http://site.blog.com/files/. Отдачей файла клиенту занимается файл /wp-includes/ms-files.php:

server {
#...

location ^~ /files/ {
rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
}

#...
}

В такой конфигурации отдавать файл клиенту будет сам WordPress (PHP), и при достаточной нагрузке мы столкнёмся с проблемами производительности. Поэтому настроим возможность отдачи файлов клиенту средствами nginx:

server {
#...

location ^~ /files/ {
rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
}

location ^~ /blogs.dir/ {
internal;
root /path/to/blog/wp-content/;
}

#...
}

Директива internal защищает файлы от прямых обращений, минуя /wp-includes/ms-files.php.

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

Затем добавляем следующую строку в /wp-config.php:

define('WPMU_ACCEL_REDIRECT', true);

После этого WordPress будет передавать заголовок X-Accel-Redirect с именем файла nginx, а nginx будет отдавать его клиенту. В результате скрипт PHP будет завершаться очень быстро и сможет обслуживать других клиентов.

Патч для php-cgi, позволяющий конфигурировать значение listen backlog

Vladimir — Sun, 03 Jan 2010 06:19:20 +0000

Задание listen backlog через переменную окружения PHP_FCGI_LISTEN_BACKLOG

По умолчанию значение listen backlog в php-cgi жёстко задано — 128. Это означает, что PHP не сможет обработать более 128 запросов одновременно (точнее, что очередь запросов не сможет превысить данного значения). Я столкнулся с тем, что 128 — это мало.

Для тех, кто столкнулся с данной проблемой, но по каким-либо причинам не хочет/не может поставить php-fpm (в котором backlog конфигурируется), я сделал небольшой патч.

--- php.orig/sapi/cgi/cgi_main.c.orig 2009-06-09 13:29:39.000000000 +0000
+++ php/sapi/cgi/cgi_main.c 2010-01-03 04:44:34.000000000 +0000
@@ -1523,7 +1523,15 @@

#if PHP_FASTCGI
if (bindpath) {
- fcgi_fd = fcgi_listen(bindpath, 128);
+ int backlog = 128;
+ if (getenv("PHP_FCGI_LISTEN_BACKLOG")) {
+ backlog = atoi(getenv("PHP_FCGI_LISTEN_BACKLOG"));
+ if (backlog < 0) {
+ backlog = 128;
+ }
+ }
+
+ fcgi_fd = fcgi_listen(bindpath, backlog);
if (fcgi_fd < 0) {
fprintf(stderr, "Couldn't create FastCGI listen socket on port %s\n", bindpath);
#ifdef ZTS

Применять к файлу sapi/cgi/cgi_main.c.

Что даёт: значение backlog можно задавать в переменной окружения PHP_FCGI_LISTEN_BACKLOG.

Проверялось на PHP 5.2.10-2ubuntu6.3 (Ubuntu 9.10).

Установка в Debian/Ubuntu:

mkdir php && cd php
apt-get source php5-cgi
sudo apt-get install devscripts build-essential wget
sudo apt-get build-dep php5-cgi
cd php5-*
QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null push -a
wget http://d.sjinks.pro/listen-backlog-env-var.patch -O debian/patches/listen-backlog-env-var.patch
QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null import debian/patches/listen-backlog-env-var.patch
QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null push -a
QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null pop -a
debuild clean
debuild -i -us -uc -b

Практические результаты: при помощи ab генерировалась сильная нагрузка (DoS) на сервер (10,000 запросов в 200 параллельных потоков):

ab -n 10000 -c 200 http://example.com/

Стандартный PHP смог обработать 2,275 запросов из 10,000 — остальные запросы были отвергнуты (502 Bad Gateway).

После применения патча и

echo 2048 > /proc/sys/net/core/somaxconn
export PHP_FCGI_LISTEN_BACKLOG=1024

и перезапуска, PHP смог обработать все запросы.

Изменилось всего-то 9 строк кода, а какой результат!

WP Super Cache vs MaxSite Cache: часть 2

Vladimir — Sun, 13 Dec 2009 08:23:41 +0000

Тест страничных кэшей на грамотно настроенном сервере

Вторая часть статьи WP Super Cache vs MaxSite Cache.

В предыдущей части я сравнивал поведение MaxSite Cache и WP Super Cache на тестовом VDS (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на котором ни операционная система, ни программное обеспечение не были специально настроены — бралась конфигурация «из коробки» и тестировалась. Одним словом, «VDS абсолютного чайника».

В этой части изменилась только конфигурация программного обеспечения: сервер настраивался на максимальную производительность.

В частности:

отказ от Apache в пользу nginx и от mod_php5 в пользу php-fcgi (количество FastCGI-процессов выбиралось таким образом, чтобы избежать использования файла подкачки);
смена ядра с linux-image-server на linux-image-virtual;
настройка MySQL: отказ от InnoDB (экономит примерно 100 МБ памяти), увеличение буфера ключей и т.п.;
установка и настройка xCache (я исходил из того, что далеко не все чувствуют себя комфортно при сборке программ из исходников, поэтому брал только готовое ПО);
настройка iptables для фильтрации пакетов.

Методика тестирования осталась прежней: карта сайта преобразовывалась в список адресов, на этот список натравливался siege, а я присматривал за сервером и вносил коррективы в конфигурацию ПО (да, с первого раза трудно всё настроить идеально).

Чтобы убедиться, что новая конфигурация не хуже старой, я полностью отключил кэширование и имитировал 50 одновременных посетителей в течение 15 минут. На момент выполнения теста у сервера было свободно 348.5 МиБ памяти.

	Голый WordPress
Количество транзакций	4,825
Доступность сервера	99.98%
Объём данных, МБ	28.32
Среднее время ответа, с	9.23
Частота транзакций в секунду	5.36
Пропускная способность, МБ/с	0.03
Коэффициент параллельности	49.50
Максимальная длина транзакции, с	30.76
Минимальная длина транзакции, с	1.15
Максимальная загрузка процессора (system/user)	25.72%/68.39%
Load Average	40.81
Примерное потребление памяти, МиБ	414

Данные загрузки/потребления памяти очень приблизительны. Хотя вряд ли пользователи станут ждать по 9 секунд загрузку страницы, радует, что сервер не ответил только на один запрос и не ушел в нокдаун. Простая экстраполяция показывает, что сервер выдержит примерно 463,000 обращения к PHP-страницам в сутки.

Мы убедились, что новая конфигурация вполне жизнеспособна (старой до неё, как до Китая в неудобной позе), переходим к тестированию плагинов.
Тестирование проходило в 30 и 75 потоков. Я не разделял фазы построения и использования кэша.

	MaxSite Cache (30 потоков)	MaxSite Cache (75 потоков)	WP Super Cache (30 потоков, HALF ON)	WP Super Cache (30 потоков)	WP Super Cache (75 потоков)
Количество транзакций	176,684	182,604	5,069	198,160	189,686
Объём данных, МБ	1,062.24	1,099.60	29.99	1,202.95	1,147.33
Среднее время ответа, с	0.13	0.34	5.30	0.10	0.29
Частота транзакций в секунду	196.36	203.00	5.64	220.20	210.95
Пропускная способность, МБ/с	1.18	1.32	0.03	1.34	1.28
Коэффициент параллельности	25.42	69.32	29.85	23.05	62.16
Максимальная длина транзакции, с	21.08	26.12	15.06	22.78	25.03
Минимальная длина транзакции, с	0.00	0.00	0.48	0.00	0.00
Load Average	1.8	2.2	30.1	1.3	1.65

Краткие выводы: на грамотно настроенном сервере лидирует WP Super Cache — и по скорости, и по создаваемой нагрузке. Это связано с тем, что задача по отдаче закэшированного контента переложена на web-сервер. Так как web-сервер справляется со статикой быстрее, чем с динамикой, в результате получаем рост производительности и снижение нагрузки.

Если по той или иной причине WP Super Cache не может работать в режиме Full On, то MaxSite Cache будет всё же предпочтительнее — ввиду своей простоты он обладает исключительным быстродействием.

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

Vladimir — Mon, 13 Apr 2009 22:22:25 +0000

Программное решение досадных мелочей с nginx

Переведя несколько сайтов с Apache на nginx, уже который раз встречаю подводные камни. Один из них — нежелание WordPress понимать код редиректа, другая — постоянные попытки использовать PATHINFO-пермалинки вместо «нормальных» (pretty permalinks).

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

Будучи активированным, плагин устанавливает собственные обработчики событий только в том случае, если сервер работает под управлением nginx, поэтому плагин без вреда (но и без всякой пользы) можно активировать на сервере с Apache — конфликтов не будет.

Текущая версия плагина решает следующие проблемы:

Когда WordPress обнаруживает, что используется FastCGI SAPI, он отказывается посылать коды перенаправления, отличные от 302. Это приводит к тому, что при использовании неканонических ссылок PageRank от «неканонической» страницы не передаётся «канонической». Я где-то читал, что использование кода 302 для склеивания страниц может караться поисковиками; так это или нет, утверждать не берусь. Плагин исправляет этот недочёт WordPress методом, аналогичным описанному здесь: только вместо физического исправления файла функция wp_redirect() просто переопределяется в другом файле.
Страница настроек постоянных ссылок полагается на наличие mod_rewrite: если он загружен, используются красивые ссылки, если нет — используются «почти» красивые ссылки вида PATHINFO. Что же, разработчики пользуются Apache. Так как nginx не использует модули и API Apache, функция, проверяющая наличие mod_rewrite, скажет, что он не загружен. Тем не менее, nginx умеет переписывать адреса, и использование PATHINFO не оправдано. Поэтому плагин «заставляет» WordPress думать, что mod_rewrite всё-таки загружен и можно использовать нормальные постоянные ссылки.

Скачать nginx Compatibility 0.1.

WordPress, FastCGI и редирект 301: часть 2

Vladimir — Fri, 13 Mar 2009 18:16:57 +0000

Патч, исправляющий проблему редиректа с кодом 302 в FastCGI

Более изящное решение, нежели представленное в первой части (WordPress, FastCGI и редирект 301).

В первой части предлагалось при использовании web-сервера nginx закомментировать проверку на SAPI PHP (if ( php_sapi_name() != 'cgi-fcgi' )). Однако есть лучшее решение.

Сразу оговорюсь, что в официальном релизе оно вряд ли скоро окажется (ибо работает с PHP 4.4+, а разработчики WordPress хотят поддерживать такое старьё, как PHP 4.3), поэтому применять данное решение только на свой страх и риск.

Патч в формате unified diff (применять к wp-includes/pluggable.php):

--- trunk/public/wp-includes/pluggable.php (original)
+++ trunk/public/wp-includes/pluggable.php (modified)
@@ -845,9 +845,7 @@
if ( $is_IIS ) {
header("Refresh: 0;url=$location");
} else {
- if ( php_sapi_name() != 'cgi-fcgi' )
- status_header($status); // This causes problems on IIS and some FastCGI setups
- header("Location: $location");
+ header("Location: $location", null, $status);
}
}
endif;

Идея в том, чтобы переложить ответственность по отправлению кода перенаправления на PHP (который справляется с этим успешнее, чем WordPress). Решение является рабочим, жалоб пока нет

UPDATE: для nginx есть лучший способ: плагин nginx Compatibility.

WordPress, FastCGI и редирект 301

Vladimir — Thu, 05 Mar 2009 16:31:18 +0000

Как заставить WordPress посылать код 301 при использовании FastCGI

Всё-таки удивительная штука WordPress… Сегодня чисто случайно обнаружил, что если PHP работает в режиме FastCGI (например, связка WordPress + nginx + PHP), то все редиректы с кодом 301 (Permanent Redirect) превращаются в редиректы с кодом 302 (Temporary Redirect).

Чем это грозит? Если Вы занимаетесь ~~спамом~~SEO, то Вы, вероятно, знаете, что переход с кодом 302 не передаёт PageRank. Иными словами, если Вы изменили структуру пермалинков или по той или иной причине в Google "раскручена" страница с несколько другой постоянной ссылкой (например, http://example.com/?p=202), то «канонический редирект» (см. wp-includes/canonical.php) не передаст PageRank целевой странице.

Еще раз повторюсь, это актуально только в случае использования PHP в режиме FastCGI (и для IIS, но это оффтопик).

Есть два способа решения проблемы:

Написание плагина, реализующего свой вариант wp_redirect() (функция wp_redirect() определена в wp-includes/pluggable.php, что даёт возможность её переопределения);
Изменение кода wp_redirect() в wp-includes/pluggable.php

Я рассмотрю только второй вариант.

В оригинале функция wp_redirect() выглядит следующим образом:

Всё, что требуется — закомментировать строку if ( php_sapi_name() != 'cgi-fcgi' ). При этом не забываем прочитать комментарий разработчиков: This causes problems on IIS and some FastCGI setups.

Должно получиться что-то вида:

Не забываем сохранить файл, после чего редиректы с кодом 301 останутся редиректами с кодом 301

UPDATE: для nginx есть лучший способ: плагин nginx Compatibility.

Конфигурация nginx для WordPress: критический взгляд со стороны

Vladimir — Thu, 18 Dec 2008 11:25:21 +0000

Можно ли сделать лучше?

Update: статья писалась давным-давно, правильная конфигурация nginx для работы с WordPress описана здесь.

Три недели назад я рассказывал про одну из конфигураций nginx для WordPress. С тех пор я получил пару отзывов, что так делать неправильно с ссылкой на конфигурацию, одобренную Игорем Сысоевым (автором nginx). Лежит она здесь:

This has the approval of Igor, the creator – you cannot get better than that.

На серверах, которые мне пришлось переводить на nginx, стояла версия 0.6.34 (версию 0.7.сколько-то там пришлось снести из-за того, что она сегфолтилась при обработке некоторых запросов, а анализировать core dump нет желания).

Рассмотрим предлагаемую конфигурацию:

server {
listen 80;
server_name michaelshadle.com;
index index.php;
root /home/mike/web/michaelshadle.com/;
include /etc/nginx/defaults.conf;
include /etc/nginx/expires.conf;
error_page 404 = /wordpress/index.php?q=$request_uri;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:11000;
}
}

Начнём с того, что WordPress не требует параметр q в запросе: достаточно взглянуть на правила, которые он генерирует для Apache. Но это всё, по сути, мелочи.

Такая конфигурация тоже является рабочей, но есть одно «но»: если пользователь запрашивает несуществующий PHP-файл (например, опечатался), то ему прилетает экран с недружественным сообщением «No input file specified». К сожалению, для моего случая это было критично, ибо пользователь в такой ситуации должен был видеть немного другую страницу.

Есть еще одна конфигурация (правда, для Drupal), написанная Игорем Сысоевым. Если её перевести на WordPress, то получится предыдущий вариант, только хуже: помимо «No input file specified», на все 404 ошибки выдавался код 200 (!).

Конфигурация выглядела так:

server {
server_name dev.example.com;
index index.php;
root /var/www/dev.example.com;

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

location @wordpress {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /var/www/dev.example.com/index.php;
include /etc/nginx/fastcgi_params;
}

location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/dev.example.com$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}
}

Вот что получалось при обращении к dev.example.com/x/ph:

Первый ответ 302 — это редирект с dev.example.com/x/ph на dev.example.com/x/ph/
А второй ответ 200 — это то, что не должно случаться. Это, кстати, объясняет баг, который я нашел в All in One SEO Pack.

Взяв две рассмотренные конфигурации за основу, я создал третью, рабочую:

server {
server_name dev.example.com;

index index.php;
root /var/www/dev.example.com;

location / {
log_not_found off;
error_page 404 = /index.php;
}

location = /index.php {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /var/www/dev.example.com/index.php;
include /etc/nginx/fastcgi_params;
}

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

fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/dev.example.com$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}
}

Так как Игорь Сысоев говорит, что обычно практикуемая прямая трансляция правил […] достойна всяческого порицания, то такая конфигурация должна быть относительно хорошей. Хотя на мой взгляд, проверка существования файла делается что с rewrite, что без; видимо, в случае с nginx rewrite является довольно дорогой операцией (хотя, возможно, для -e выполняется лишний stat, не знаю).

WordPress: заменяем Apache mathopd’ом

Vladimir — Tue, 25 Nov 2008 17:00:26 +0000

Дружим WordPress и mathopd

Вторая статья из серии "WordPress: Заменяем Apache лёгким web-сервером".

Первая статья была посвящена nginx, в данной статье разберём особенности конфигурирования mathopd и WordPress для совместной работы.

В Ubuntu/Debian нам понадобится пакет libfcgi0ldbl, содержащий программу cgi-fcgi, которую mathopd использует в качестве обёртки для FastCGI:

aptitude install libfcgi0ldbl

Или можно попробовать собрать обёртку с исходников.

Как и в прошлом случае, мы предполагаем, что PHP в режиме FastCGI прослушивает 9000 порт на 127.0.0.1

Server {
Port 80
Address 0.0.0.0
Virtual {
Host example.com
Control {
Alias /
Location /var/www/example.com
ScriptUser nobody

External {
"/usr/bin/cgi-fcgi -bind -connect 127.0.0.1:9000" { .php }
}
}
}
}

Особенностью работы под mathopd является то, что он не предоставляет функциональности для переписывания адресов (как mod_rewrite в Apache), поэтому пермалинки будут всего лишь "Almost Pretty".

При тестировании данной конфигурации обнаружилась одна интересная особенность, которую, вероятно, стоит считать ошибкой mathopd: если демон web-сервера слушает нестандартный (не 80) порт, то WordPress уходит в вечный цикл редиректов.

Причина здесь в следующем: mathopd, в отличие от других серверов, не добавляет порт в переменную $_SERVER["HTTP_HOST"]. Таким образом, для example.com:8080 $_SERVER["HTTP_HOST"] в mathopd будет example.com (nginx, например, укажет значение example.com:8080).

В WordPress есть интересная процедура — redirect_canonical, которая пытается привести URL к каноническому виду (типа, SEO friendly). В ней есть интересные строки:

if ( !$requested_url ) {
// build the URL in the address bar
$requested_url = ( !empty($_SERVER['HTTPS'] ) && strtolower($_SERVER['HTTPS']) == 'on' ) ? 'https://' : 'http://';
$requested_url .= $_SERVER['HTTP_HOST'];
$requested_url .= $_SERVER['REQUEST_URI'];
}

В случае mathopd и http://example.com:8080/, $requested_url будет установлен в http://example.com/. Так как форма этого URL не будет совпадать (из-за того, что порт потерялся) с формой, хранимой в базе данных, WordPress сделает перенаправление на http://example.com/, и так будет продолжаться до бесконечности.

Для решения проблемы придётся закомментировать строку add_action('template_redirect', 'redirect_canonical'); в файле /wp-includes/canonical.php.