По совету коллеги прикрутил к своему хостингу APC — кэш байткода PHP. При выполнении PHP скрипта происходит трансляция программы на языке PHP в специальный байткод (этакий виртуальный ассемблер), который уже непосредственно исполняется. APC позволяет сохранять результат трансляции в памяти, таким образом уменьшая время выполнения скрипта.
Ставится очень просто:
apt-get install php5-apc /etc/init.d/php5-fpm restart
Замеры показали, что время отдачи главной страницы уменьшилось почти в 2 раза.
ЭВМ/ IT-хозяйство: веб-хостинг
31.03.2010Осталось рассказать, какой софт я развернул на своей VPS. Как я уже говорил, Linode делает свои виртуалки на базе Xen, причем в режиме паравиртуализации. А это, в свою очередь, означает, что выбор ОС сильно ограничен: или Linux, или какой-то другой Linux. Нет, конечно есть вполне рабочий порт NetBSD на Xen, есть порт FreeBSD, были даже попытки запустить OpenBSD на этой архитектуре. Но, во-первых, я не слышал, чтобы кто-то делал веб-хостинг на NetBSD, а FreeBSD на мой взгляд ничем не лучше Linux.
Вообще я не очень люблю Linux, но и какой-то патологической ненависти к нему не испытываю. Поэтому к идее развернуть свое хозяйство на этой ОС отношусь спокойно. Кроме того, все последние годы деньги мне платили именно за работу с Linux. Так что опыт кое-какой имеется. Сам я слабо разбираюсь в тонкостях современных дистрибутивов Linux и в том, как устроен веб-хостинг. Но многие коллеги на нынешней работе имеют в этой области хороший опыт, поэтому я все делал, основываясь на их рекомендациях.
После выбора тарифного плана на Linode необходимо решить, какую операционную систему развернуть. Из всего списка я остановился на (точнее мне посоветовали) Debian 5.0 Lenny. Забегая наперед скажу, что система мне понравилась: удобный менеджер пакетов, сами пакеты сделаны хорошо, избавляют от большого количества рутиной работы по первичной настройке. Через несколько секунд новая виртуальная машина готова к работе. Зайти на нее можно либо через AJAX консоль, либо по ssh. Консоль также доступна через ssh-интерфейс (что-то вроде serial console по сети), они ее называют красивым именем Lish — Linode Shell, хотя на самом деле это обычная Xen console. Итак, залогинившись можно приступать к настройке.
В качестве веб-платформы я решил (опять-таки послушав умных людей) использовать связку nginx + PHP-FPM + MySQL. nginx — потому что монстр Apache мне не нужен, PHP-FPM — толковая реализация FastCGI для PHP, которая кушает мало памяти (а память на моем VPS сильно ограничена), а MySQL — он и в Африке MySQL, не PostgreSQL же ставить в самом деле.
С nginx и MySQL никаких проблем не возникло, оба пакета нашлись в стандартном репозитории Debian. А вот с PHP-FPM не все просто. PHP-FPM — суть сторонний патч для PHP, и только совсем недавно было принято решение включить его в следующую версию PHP. А до сих все прикладывали его вручную, а самые продвинутые делали собственный пакет. Оба этих варианта мне не годились, потому что у меня совсем нет времени делать и поддерживать наколенные поделки, свои или чужие. Легкое гугление показало, что есть добрые люди, которые не только собрали нужный мне пакет, но и создали для него репозиторий и готовы пакет поддерживать. Но на практике оказалось, что их пакеты уже остали от обновлений Debian Security, поэтому эту затею пришлось оставить.
Дальнейшее гугление привело меня на сайт Dotdeb. И там наконец обнаружился добротный пакет PHP-FPM, но только для PHP 5.3, тогда как в Lenny по умолчанию идет 5.2. Но так как мне было все равно, какую версию PHP ставить, я его и взял. Впоследствии правда оказалось, что есть небольшие проблемы этой версии с некоторыми плагинами для WordPress, но в остальном все отлично.
Теперь осталось только выбрать движок для блога. Так как я этой темой никогда особо не интересовался, то взял самый популярный — WordPress. И, надо сказать, не жалею. Интерфейс приятный, удобный, работает быстро. За пол дня подточил стандартную тему — и новый непорядок готов!
Задумал я на базе этого блога сделать себе OpenID. OpenID — это способ идентифицировать и аутентифицировать себя на многих web-сервисах с помощью одной учетной записи. Фактически это означает, что получив один раз OpenID, можно больше не регистрироваться на сотне сайтов только ради того, чтобы читать приватные записи или писать комментарии. Конечно, эти сотни сайтов должны поддерживать OpenID. Получить OpenID можно во многих местах абсолютно бесплатно, например в том же LJ. Или настроить OpenID provider у себя в standalone блоге.
Вообще, я много лет жил без OpenID и прожил бы еще столько же, но недавно мой хороший друг уехал далеко-далеко и стал описывать свое новое житье в LJ. А так как он слегка страдает паранойей, все его записи доступны только «для друзей». Конечно, можно было завести технический аккаунт в LJ, единственной целью которого было бы предоставление доступа к приватным записям, но это совсем не комильфо.
В целом задача выглядела очень простой. Для WordPress (а этот блог работает именно на нем, если вдруг кто не понял) есть специальный плагин, который так и называется — OpenID, он предоставляет функционал как потребителя OpenID (для тех же комментариев), так и провайдера. Однако после установки плагин не заработал, так что пришлось засучить рукава и выяснять почему. Для тестирования в качестве потребителя OpenID использовался все тот же LJ.
Первое, что нагуглилось сразу — текущая версия OpenID 3.3.2 не работает с PHP 5.3, а именно его я использую по ряду причин. Патчик, исправляющий проблему, очень простой и действительно рабочий. Кроме того автор патча утверждает, что обратная совместимость не ломается, так что есть надежда, что в новой версии плагина эта проблема будет исправлена. Однако в Subversion репозитории проекта этого патча почему-то нет. На всякий случай я напомнил автору OpenID об этой проблеме.
Вторая проблема была связана с тем, что при авторизации возникал переход по адресу вида http://blog.name/index.php/openid/server…, который заканчивался ошибкой 404. Эта проблема также известна, и даже есть кривая заплатка. Чтобы понять ее причину и, главное, найти правильное решение, нужно сделать шаг в сторону и выяснить, как устроены постоянные ссылки в WP.
Постоянные ссылки на записи не меняются со временем и могут быть использованы на внешних ресурсах. По умолчанию WP генерирует постоянные ссылки вида http://blog.name/?p=123. Они не очень красиво выглядят, так как содержат в себе CGI параметры. «Красивые» ссылки вида http://blog.name/raznoe/kak-ya-provel-leto возможны при наличии mod_rewrite в Apache или соответствующих правил в конфигах lighttpd или nginx. Есть еще одна возможность, из-за которой собственно все и не работает — так называемые «почти красивые ссылки», или PATHINFO permalinks. Ссылки такого типа выглядят как http://blog.name/index.php/raznoe/kak-ya-provel-leto.
Метод PATHINFO (точнее даже PATH_INFO) работает только в Apache и использует одну его интересную особенность: по умолчанию URI вида /path/script.cgi/another/path, при наличии скрипта path/script.cgi, приводят к вызову обработчика этого скрипта, при этом устанавливается специальная переменная окружения PATH_INFO со значением равным /another/path.
У меня Apache нет, вместо него стоят nginx и php-fpm. В конфиге nginx присутствуют строчки, эмулирующие поведение mod_rewrite:
if (!-e $request_filename) {
rewrite . /index.php last;
}
Вообще говоря, господин Сысоев всячески порицает (см. самый низ страницы) подобные конфиги, однако рекомендуемая им директива try_files присутствует только в nginx 0.7.x, тогда как у меня в Debian Lenny nginx версии 0.6.x, и менять его пока желания нет.
С nginx и его rewrite отдельная очень интересная история. Если зайти на страницу конфигурирования WP в раздел постоянных ссылок, то можно увидеть такую картинку:
Как видно, в качестве альтернативы «некрасивым» ссылкам WP предлагает использовать PATHINFO, которое не работает в nginx! Происходит это из-за того, что WP проверяет имя сервера, и если оно не Apache, или если Apache, но не загружен модуль mod_rewrite, то для постоянных ссылок по умолчанию включается режим PATHINFO. Справедливости ради надо отметить, что на самом деле правила rewrite для nginx, приведенные выше, все-таки заставляют схему с PATHINFO работать. Видимо, WP внутри себя как-то решает эту проблему. Но вот его плагины, в частности OpenID — нет, из-за чего собственно весь сыр-бор.
Так вот, оказывается, существует специальный плагин nginx Compatibility, который, во-первых, сообщает WP, что mod_rewrite как будто бы присутствует, а во-вторых, чинит какую-то проблему с FastCGI PHP SAPI, которая нас сейчас не интересует.
После активации плагина страница настроек стала выглядеть правильно:
По умолчанию предлагаются красивые mod_rewrite постоянные ссылки.
Но вернемся к OpenID. Проблема с ним заключена в нескольких строчках кода в файле common.php:
if ($wp_rewrite->using_permalinks()) {
$url .= 'index.php/openid/' . $service;
} else {
$url .= '?openid=' . $service;
}
Автор неявно полагает, что если включены красивые постоянные ссылки, то механизм PATHINFO точно должен работать. Как было показано выше, это верно только для Apache. Таким образом если у вас не Apache (а у меня не Apache), и вы используете красивые постоянные ссылки (а я их использую), то плагин OpenID у вас работать не будет. Замечу, что без использования красивых постоянных ссылок все работает.
Горячие головы предлагают выкинуть совсем строчки, добавляющие index.php в URI, но не думаю, что автор на это согласится, все же он эти строки не зря добавил.
Чтобы найти правильный путь, нужно поставить еще один плагин — AskApache RewriteRules Viewer. Он показывает всю внутреннюю кухню постоянных ссылок:
Видно, что свойство using_permalinks, на которое опирается OpenID, действительно истинно, но свойство using_index_permalinks, которое на самом деле показывает, что работает PATHINFO, ложно. Таким образом правильным решением будет замена в вышеприведенном куске кода using_permalinks на using_index_permalinks. После того, как это было сделано, плагин успешно заработал, а соответствующий патч был отправлен автору.