Не уверен, что выложу её – она требует повторных экспериментов, поэтому приведу выдержки, не подкрепляя их фрагментами конфигурации.

Итак, имеется сервер с Ubuntu Server 10.10. Сервер мощный – 2 x Xeon X5260@3.33GHz, 8 GB RAM, RAID 1 из двух дисков SAS 15K rpm на аппаратном RAID.

Дисковая производительность слабая по состоянию на текущий момент – всего 100 MBps:

$ sudo hdparm -t /dev/cciss/c0d0
/dev/cciss/c0d0:
 Timing buffered disk reads:  294 MB in  3.03 seconds =  96.98 MB/sec

Задача – максимизировать производительность WordPress на этом сервере.

Тесты проводил на сайте с 300 статей, запрашивая домашнюю страницу со 100 конкурентными запросами:

$ ab -n 20000 -c 100 http://benchmark.ctrld.me/

Результаты:

P.S. На данный момент я отказался от Apache, оставил nginx fastcgi_cache, но не использую никаких плагинов кеширования. На повторных обращениях к одной странице выигрыш потрясающий, однако генерация новой страницы занимает сравнительно длительное время. Я решу этот вопрос и сделаю финальную статью. Текущие результаты не привожу, так как мощность тестового сервера и VPS очень разные.

Опыт системного и сетевого администрирования у меня достаточно большой. Ещё в 1994-м году я познакомился с Linux и FreeBSD, примерно в это же время починил считавшийся безнадёжно испорченным Silicon Graphics одного пафосного рекламного агентства, что придало мне сил и уверенности в нужности знания Unix. Занимался запуском и администрированием одного национального ISP, потом датацентра, занимаясь и серверным, и сетевым оборудованием.

Четыре года назад благодаря @kostiantyn‘у приобщился к OS X, купив свой первый ноутбук Macbook.

Через два года у меня закономерно появился Macbook Pro и на волне восторга ко мне пришла идея сделать нишевый блог, в котором я смогу на базе своего опыта в Unix рассказывать о Mac OS X.

20 августа 2009 года, когда MBP лежал, завёрнутый в подарочную упаковку, я поднял сайт и разместил первую статью “WWDC-2009″, которая раньше лежала вроде бы на Tumbler’е.

Сайт работал на выделенном сервере моих друзей, находящемся в Германии. В качестве CMS я привычно выбрал WordPress, так как давно его использовал на проекте “Traverse Team“. Движок работал на Apache практически “из коробки”, никакого тюнинга, кеширования, оптимизации я не делал. Конечно, скорость генерации страниц была низка, но меня это почти устраивало – сайт по скорости (вернее сказать “медленности”) не выделялся из множества других. Операционная система была FreeBSD, под сайт я сделал jail.

Сервер был не очень мощным, к тому же через пару месяцев он стал себя странно вести – из-за Kernel Panic он напрочь вис, помогала только перезагрузка по питанию. Можно было бы для начала обновить операционную систему, но там вертелись сервисы, завязанные на определённые версии PHP/MySQL, и обновиться было практически невозможно. Но скорее всего была проблема с модулем памяти.

Как раз в это время у меня появился второй Macbook. К тому же в моём доме кроме единственного ADSL-провайдера появился второй провайдер, предлагающий подключение по Ethernet, да ещё со статическим IP. Само собой, я воспользовался появившимися возможностями, и сделал из ноутбука сервер под Mac OS X для моего сайта (часть 1, часть 2, часть 3).

Сайт проработал на этом ноутбуке, перемещавшемся с кухонного шкафа на холодильник и обратно, три месяца с января по март 2010 года. Всё было бы хорошо, но вечерами люди в локальной сети занимались скачиванием, что ухудшало откликаемость сайта, а потом две недели подряд у провайдера были проблемы с маршрутизацией сети апстримам, что приводило к пропаданию анонсов на стыке Telia – Level3. Недоступность сайта по часу в день для блога некритична, но не реагировать было по крайней мере невежливо по отношению к читателям.

После анализа предложений я остановился на Linode и перенёс сайт на VPS. Полтора года пользуюсь сервисом и очень доволен. Взял VPS Linode 512 с 512 MB RAM (хочется больше, но денег жаль).

В процессе настройки я остановился на комбинации Nginx (фронтэнд) + Apache (бэкэнд) + привычный плагин кеширования W3 Total Cache. В процессе настройки обращался к сайтам Juev и Snupt (конкретные статьи искать лень, почитайте сайты сами, не пожалеете).

Скорость генерации была нормальная, но хотелось большего. Через некоторое время стал использовать в nginx кеширование проксированных ответов от Apache с патчем выборочного очистки кеша и плагином под WordPress. Сайт стал носиться. От 2 запросов в секунду на голом Apache я пришёл к 5000 запросов. Неплохо.

Всё было бы хорошо, но 512 MB RAM маловато для того, чтобы держать два web-сервера, MySQL, да ещё и memcached для W3 Total Cache. На днях я “попал”. Из-за нехватки памяти я потерял все настройки темы (а их было много, включая кастомный CSS). Хорошо, что старые страницы были в кеше и я смог восстановить данные (бекап, конечно, есть, я делаю дамп MySQL раз в сутки и файлы раз в 4 часа, но восстанавливаться с нуля не хотел).

Поэтому сделал “ход конём”. Убрал memcached, W3 Total Cache, Apache. Оставил только nginx, php запустил в fastcgi и настроил nginx fastcgi_proxy. При concurrency level 100 при тестах с самого сервера получаю под 5000 запросов в секунду. К тому же избавился от нескольких лишних компонентов. Памяти хватает.

Статья была “лирикой”. Если хотите деталей, как всё сконфигурировано, пишите в комментариях – если будут желающие, то я напишу отдельную статью.

ProxyPass        /news/  http://internal.company.com/
ProxyPassReverse /news/  http://internal.company.com/

Всё работает хорошо, до тех пор, пока на внутреннем сервере вместо относительных URL вида “/css/style.css” не появляются абсолютные URL “http://internal.company.com/css/style.css”. В этом случае html возвращается внешнему клиенту, он пытается взять css/js или перейти по внутреннему адресу http://internal.company.com, который недоступен из Интернет, и на этом всё заканчивается. Страницы не отображаются, ссылки не работают.

Приходилось выкручиваться с прописыванием внешних URL на внутренних серверах, это рождало проблемы доступа из внутренней сети. Они лечились Split DNS (внутренним и внешним клиентам отдавались на один запрос разные имена). Всё это рождало дополнительные сложности, в итоге с трудом поддерживалось и диагностировалось.

Сегодня мне снова понадобилось решить эту задачу. Провёл изучение текущего состояния вопроса и нашёл отличное решение – mod_substitute, который к тому же входит в стандартную поставку Apache 2.2 и не требует компиляции из сторонних исходников.

Теперь конфигурация выглядит примерно так:

ProxyPass        /news/  http://internal.company.com/
ProxyPassReverse /news/  http://internal.company.com/

AddOutputFilterByType SUBSTITUTE text/html
Substitute "s|http://internal.company.com/|http://company.com/news/|in"

Замечу – нагрузка на сервер минимальна, нужно переписывать только text/html. Для других случаев понадобится более расширенная конфигурация. Но направление решения вопроса я показал, от чего-то уже можно оттолкнуться.

Изначально я использовал чистый Apache, потом перешёл на чистый nginx, потом – на связку nginx как frontend и apache как backend. Но не остановился на этом и улучшил производительность за счёт применения nginx cache. Спасибо за рекомендации Денису (Juev) и Диме (Snupt). Детали я опишу в отдельной статье, указав конкретные статьи, мысли и проблемы. Теперь осталось закончить, проведя минификацию css и js – этим займусь, как только появится время.

Мой сайт работает под Ubuntu Server. В процессе настройки возникали нюансы, которые было тяжело диагностировать, не понимая, что именно происходит. И если под Mac OS X я активно для этого использую dtrace, а под FreeBSD когда-то запускал ktrace, то под Linux мне не доводилось ничего подобного делать.

Время пришло и мне помог strace.

Суть вопроса была в том, что я ставил дополнительный модуль ngx_cache_purge по рецепту, описываемом в статье “WordPress nginx proxy cache“, но при обращению к нужному URL вместо информации о выполненном действии я получал код 404. Я понятия не имел – вызвано это проблемой в конфигурации или же модуль попросту не работал. Был вариант вставлять директивы отладки в код модуля и перекомпилировать nginx, но это было трудоёмко и неоперативно.

Процесс отладки с помощью strace прост. Сначала нужно определить pid’ы интересующих процессов:

$ pidof nginx
6029 6028 6027 6026

А потом подключиться к этим процессам:

$ sudo strace -Ff -tt -p 6029 -p 6028 -p 6027 -p 6026
[pid  6027] 18:16:17.711733 <... epoll_wait resumed> {{EPOLLIN, {u32=143765384, u64=290081331106393992}}}, 512, -1) = 1
[pid  6027] 18:16:17.711817 gettimeofday({1289146577, 711843}, NULL) = 0
[pid  6027] 18:16:17.711955 accept(9, {sa_family=AF_INET, sin_port=htons(36923), sin_addr=inet_addr("94.45.55.146")}, [16]) = 13
[pid  6027] 18:16:17.712135 ioctl(13, FIONBIO, [1]) = 0
[pid  6027] 18:16:17.712271 epoll_ctl(11, EPOLL_CTL_ADD, 13, {EPOLLIN|EPOLLET, {u32=143765568, u64=13827881989708034112}}) = 0
[pid  6027] 18:16:17.712409 epoll_wait(11, {{EPOLLIN, {u32=143765568, u64=13827881989708034112}}}, 512, 60000) = 1
[pid  6027] 18:16:17.712572 gettimeofday({1289146577, 712607}, NULL) = 0
[pid  6027] 18:16:17.712758 brk(0x898c000) = 0x898c000
[pid  6027] 18:16:17.712892 recv(13, "GET /purge/archives/4638 HTTP/1."..., 131072, 0) = 613
[pid  6027] 18:16:17.713240 open("/var/lib/nginx/cache/b/22/d2587efb52d796c83c14d80388e4322b", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid  6027] 18:16:17.713696 writev(13, [{"HTTP/1.1 404 Not Found\r\nServer: "..., 202}, {"b4\r\n", 4}, {"\37\213\10\0\0\0\0\0\0\3", 10}, {"\355\216\261\16\3020\fDw$\376\301t\217\2R\307\220\5\201\304\0\v_\220\326&\211\224\306(\4"..., 170}, {"\r\n0\r\n\r\n", 7}], 5) = 393
[pid  6027] 18:16:17.713926 write(5, "94.45.55.146 theapplegeek.ru - ["..., 243) = 243

Виден процесс работы приложения и из него я увидел, что 404 возникает из-за отсутствия в кеше /var/lib/nginx/cache файла. Т.е. модуль работает, и после изучения конфигурации я нашёл опечатку в описании ключа кеширования. Польза налицо. Рекомендую.

Достоинства:

• Ускоряется загрузка сайта за счёт того, что контент располагается на ближайших серверах CDN.
• Уменьшается нагрузка на сайт, так как не приходится раздавать множество изображений и других файлов, движок WordPress генерирует только страницу, а всё остальное подтягивается из CDN. Это снижает требования к хостингу.
• Уменьшается трафик, ведь большинство трафика создают изображения. Это также приводит к экономии.

Стоимость сервиса очень демократичная. На текущий момент у блога 300 уникальных посетителей в день и 600 RSS-подписчиков с fullfeed. И за это я плачу порядка $2-$3 в месяц:

Три месяца я держал свой блог на ноутбуке MacBook, стоящем на кухне – он плавно перемещался под потолком с кухонного шкафа на холодильник и обратно. Процесс установки блога на Mac OS X я детально описал в статьях: “Часть 1, MySQL“, “Часть 2, Apache” и “Часть 3, кеширование“.

Но в последние недели я стал замечать, что по какой-то непонятной для меня причины подсеть моего домашнего провайдера становится недоступной на переходе Telia – Level3. Если бы это был одинарный случай, то я бы не беспокоился. Но две недели подряд – это уже перебор.

В итоге я принял решение перейти на внешний хостинг.

К хостингу, особенно местечковому, у меня отношение сугубо отрицательное. Хостинг-провайдеры зарабатывают деньги. И разместить 200 клиентов на сервере, который может нормально обслужить всего 100 клиентов – это нормальная ситуация. И начинаются войны – клиенты требуют от провайдера сервиса, а провайдер обвиняет клиентов в создании излишней нагрузки и заставляет переходить на другой тариф. Всё это сопровождается непродуманностью технических возможностей – даже WordPress проблематично запустить из-за искусственно заниженных ограничений по памяти. В итоге shared-хостингом и VPS недовольны все. Поэтому местных хостинг-провайдеров я даже не рассматривал.

Самый правильный вариант – это выделенный сервер. Но прямой прибыли мои проекты не приносят, и платить $100-$200 никакого желания у меня нет.

Пересматривая заметки в Google Reader, я наткнулся на сравнительный анализ сервисов VPS Amazon, Rackspace, Linode и ещё двух компаний. Linode по большинству параметров опередил, и я решил попробовать.

Linode предлагает Xen-хостинг. Я взял минимальный пакет Linode 360 с 360 MB RAM.

Конечно, перенос блога об Apple с Mac OS X на Linux не совсем кошерно, и я не оправдываю часть названия “The Apple”. Зато “Geek”‘овость не страдает. Мне ещё с времени экспериментов с Amazon нравится Ubuntu, поэтому я создал VPS на Ubuntu 9.10 в Лондонском датацентре:

Процесс установки и переноса прошёл практически гладко, я даже не заметил ограничения по памяти. Мне показалось, что сайт стал работать немного медленнее, но это можно списать на территориальную удалённость площадки. Сейчас всяческие локальные сети обмена трафиком вроде UA-IX, MSK-IX уже кажутся рудиментом, и я предпочитаю держать ресурсы подальше от родины, тем более, что цена вопроса – какие-то смешные 50 ms RTT.

Да и стоимость меня очень даже устраивает. Кстати, @myfreeweb порекомендовал сервис (dv) компании Media Temple. Но я хочу пока побыть на Linode, тем более, что за месяц я уже заплатил.

Кроме всего прочего у Linode есть клиент под iPhone:

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

See you,
Serdyukov Oleg

Update 17.08.2010. Я по-прежнему на Linode и мне нравится. Если вы решите и сами воспользоваться Linode, то можете зарегистрироваться, используя мою реферальную ссылку.

Изображение из заголовка я взял с AllThingsDistributed.

Для любого сайта важны контент, скорость и дизайн. Без качественного контента не будет посетителей, плохая скорость их рано или поздно отпугнёт, плохой дизайн тоже не придаст особой любви даже при хорошем контенте (но это на последнем месте, так как многие посетители читают обновления только через RSS). Контент и дизайн – вещи творческие, а вот скорость технологична, её можно обеспечить за счёт применения некоторых рекомендаций и настройки софта. Самое качественное и полное руководство – это документ Yahoo “Best Practices for Speeding Up Your Web Site“. Если его выполнить, то можно добиться значительного ускорения работы своего сайта.

Для аудита есть плагин Firefox YSlow, разработанный Yahoo. Он работает совместно с FireBug. В этой части я не буду останавливаться на нём, расскажу в отдельной части.

Один из важных пунктов в оптимизации – это “Use a Content Delivery Network”. Все Content Delivery Network служат для быстрой и надёжной географически распределённой доставки статического контента. Вот как раз об этом и поговорим.

У Amazon есть свой CDN – CloudFront. Описание и практические принципы работы расписаны в Getting Started Guide, я не буду их здесь дублировать, а покажу, как практически разместить свои данные в CloudFront.

Предупреждение: услуга Amazon CloudFront платная, тарифы есть на сайте Amazon.

Для начала активируем сервис, для чего идём на страницу CloudFront:

Sign Up For Amazon CloudFront. Будет запрошен логин/пароль:

Можно ознакомиться с ценами и проверить биллинговые данные, после чего нажать “Complete Sign Up”:

Сервис активирован:

Работать с CloudFront можно через AWS Management Console:

Но гораздо проще – через бесплатную утилиту Cyberduck. Я собирался привычно рассказывать о работе с системой через консоль, но в процессе создания S3 Bucket с удивлением увидел, что Cyberduck прекрасно работает не только с S3, но и с CloudFront. Желающих же продолжить с консолью я направляю на Getting Started Guide, там всё прекрасно описано.

Предварительно находим и где-нибудь сохраняем AWS Access Key ID и Secret Access Key – они нам понадобятся немного позже. За ними идём на AWS, Your Account, Security Credentials:

Запускаем программу:

Создаём учётную запись S3:

Secondary click и Connect, либо просто Enter для подключения:

В поле Username вводим AWS Access Key ID, в поле Password – Secret Access Key:

Зашли в S3:

Создаю новый каталог (bucket). Имя должно быть уникально для всей системы:

Вот информация по bucket’у (Cmd+I):

В Cyberduck есть возможность сразу разместить данные в CloudFront. Для этого выставляем права:

Включаем CloudFront Distribution и логирование

Заходим в каталог и перетаскиваем туда нужный файл image.jpg:

Смотрим информацию по файлу, запоминаем URL (http://d2ggdqlo6oay4b.cloudfront.net/image.jpg):

Всё, через минут 5 можно обращаться к файлу по указанному адресу.

Обратите внимание, что в свойствах S3 регион указан “US Standard”. Его можно поменять в настройках программы, но до создания bucket’а:

Логи по обращению к файлам в CloudFront находятся в каталоге logs в нашем Bucket’е:

Всё, данные размещены, URL получен, и его можно использовать у себя на сайте. Ждите следующую часть – я расскажу о потрясающем плагине W3 Total Cache для WordPress, с ним я ускорил время загрузки страницы с 220 ms до 34 ms – согласитесь, это очень хороший результат.

Кстати, сейчас вы можете оценить работу и этого плагина, и Amazon CloudFront – они у меня активны. Один побочный эффект – пришлось отключить плагин адаптации сайта под iPhone, но я занимаюсь восстановлением его работы.

Для быстрой работы блог нужно всячески кешировать. Я использую комбинацию из нескольких способов – кеширование на уровне WordPress WP Super Cache, на уровне PHP – eAccelerator, Memcached и заодно кеширование запросов MySQL. По крайней мере хуже не становится, а улучшение производительности налицо.

Один из полезнейших плагинов WordPress – это WP Super Cache. Он из категории “must have”. Настройки:

Есть некоторые проблемы с WPTouch, поэтому нужно отключить кеширование для мобильных устройств:

Список для копирования:

bot
ia_archive
slurp
crawl
spider
iphone
ipod
android
dream
cupcake
webos
incognito
webmate
opera
mini
blackberry9530
blackberry9500

Memcached. Я его раньше не использовал, но всегда хотел. Особой эффективности для небольшой нагрузки я не заметил, но он по крайней мере работает. Процесс установки:

$ sudo port install memcached
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.memcached.plist
$ sudo port install php5-memcache

И перезапускаем apache.

Статус демона memcached можно посмотреть таким образом:

$ echo stats | nc 127.0.0.1 11211

Для того, чтобы Memcached использовался в WordPress, ставим плагин WP Memcached Manager. Настройки:

Статус работы:

EAccelerator. Нужен. Однозначно. Теория – на сайте разработчиков. Процесс установки и настройки:

$ sudo port install php5-eaccelerator
$ sudo vim /opt/local/var/db/php5/eaccelerator.ini

eaccelerator.shm_size="16"
eaccelerator.cache_dir="/tmp/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter="*.php"
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

И перезагружаем apache.

Включаем кеширование запросов в MySQL:

$ sudo vim /etc/my.cnf
query_cache_type = 1
query_cache_size = 26214400

И перезагружаем MySQL.

Статус работы:

$ mysql mysql
SHOW STATUS LIKE 'Qcache%';
SHOW STATUS LIKE 'Questions%';

И в завершение тестируем быстродействие сайта:

$ ab -n 1000 -c 1 http://theapplegeek.ru

Но и это ещё не всё. Продолжим оптимизацию уже на nginx, одно из направлений – выставление Expire для определённых типов файлов, а также компресирование ответов. Продолжение следует.

Для простоты следующим шагом в качестве web-сервера я запущу apache. Его большое преимущество в том, что php очень просто ставится, как модуль, и не требуется дополнительных ухищрений. Поэтому я запущу сайт именно под apache, а уже после этого переделаю всё под nginx, который мне нравится больше.

В Mac OS X есть штатный apache, его можно запустить в System Preferences/Sharing/Web Sharing:

Это полноценный Apache/2.2.13, но для наших целей он не подходит – PHP в портах требует установленного apache, причём из портов. Ухищряться можно было бы, но особого желания у меня делать это не было. Поэтому я спокойно смиряюсь с мыслью, что в системе будет стоять Apache родной и Apache из портов.

Установка Apache2 проста:

$ sudo port install apache2

Запуск (пока его запускать не нужно):

$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

Остановка:

$ sudo launchctl unload -w /Library/LaunchDaemons/org.macports.apache2.plist

Я привык управлять apache через apachectl, и не собираюсь изменять своим привычкам. Но apachectl от штатного Apache находится в /usr/sbin/apachectl:

$ which apachectl
/usr/sbin/apachectl

Apachectl же свежеустановленного порта лежит в /opt/local/apache22/bin/apachectl, для простоты делаем симлинк в каталог, находящийся первее в путях, чем /usr/sbin:

$ sudo ln -s /opt/local/apache22/bin/apachectl /opt/local/bin/

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

$ sudo port install php5-web
To customize php, copy
/opt/local/etc/php5/php.ini-development (if this is a development server) or
/opt/local/etc/php5/php.ini-production (if this is a production server) to
/opt/local/etc/php5/php.ini and then make changes.

$ sudo port install php5-mysql
To use mysqlnd with a local MySQL server, edit /opt/local/etc/php5/php.ini and set
mysql.default_socket, mysqli.default_socket and pdo_mysql.default_socket
to /opt/local/var/run/mysql5/mysqld.sock

Дальше полезных сообщений не будет:

$ sudo port install php5-mbstring
$ sudo port install php5-mcrypt
$ sudo port install php5-zip
$ sudo port install php5-gd
$ sudo port install php5-eaccelerator
$ sudo port install php5-openssl
$ sudo port install php5-sockets
$ sudo port install libssh2

Для eaccelerator создаю нужный каталог:

$ sudo mkdir /tmp/eaccelerator/
$ sudo chown www:www /tmp/eaccelerator/

Беру php.ini-production и делаю в нём базовые правки (тюнинг PHP-тема отдельная)

$ sudo cp /opt/local/etc/php5/php.ini-production \
	/opt/local/etc/php5/php.ini
$ sudo vim /opt/local/etc/php5/php.ini
date.timezone = Europe/Kiev
error_log = /var/log/php_errors.log
mysql.default_socket = /opt/local/var/run/mysql5/mysqld.sock

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

$ sudo touch /var/log/php_errors.log
$ sudo chown www:www /var/log/php_errors.log

Для интересующихся модули PHP поставились в каталог:

$ ls -al /opt/local/lib/php/extensions/no-debug-non-zts-20090626/
-rwxr-xr-x   2 root  admin    71880 Jan  9 22:29 eaccelerator.so
-rwxr-xr-x   2 root  admin   338560 Jan  9 22:32 gd.so
-rwxr-xr-x   2 root  admin  2031040 Jan  9 22:27 mbstring.so
-rwxr-xr-x   2 root  admin    38384 Jan  9 22:29 mcrypt.so
-rwxr-xr-x   2 root  admin    46648 Jan  9 22:26 mysql.so
-rwxr-xr-x   2 root  admin   111672 Jan  9 22:26 mysqli.so
-rwxr-xr-x   2 root  admin   117480 Jan 10 21:41 openssl.so
-rwxr-xr-x   2 root  admin    30496 Jan  9 22:26 pdo_mysql.so
-rwxr-xr-x   2 root  admin    45016 Jan 10 21:47 sockets.so
-rwxr-xr-x   2 root  admin    81680 Jan  9 22:29 zip.so

Теперь приступаем к конфигурированию Apache. Я отключаю ненужные мне модули, убираю все комментарии и вычищаю мусор. Рассказывать об этом не буду подробно, могу сказать, что и в “дефолтовом” состоянии Apache работает хорошо, главное сделать несколько коррекций, которые я приведу ниже:

$ sudo vim /opt/local/apache2/conf/httpd.conf

В конце секции загрузки модулей добавляем:

LoadModule php5_module modules/libphp5.so

Меняем строку

DirectoryIndex index.html

на

DirectoryIndex index.html index.php

Раскомментариваем включаемые файлы

Include conf/extra/httpd-mpm.conf
Include conf/extra/httpd-vhosts.conf
Include conf/extra/httpd-default.conf

Добавляем конфиг для php (файл установился, я удивился, почему сам модуль не активировался в LoadModule):

Include conf/extra/mod_php.conf

httpd-mpm.conf можем не править, там всё в порядке.

В httpd-default.conf нужно подправить параметры, которые я выделил жирным. Если на сервер будет большое количество коннектов, и, например, база данных будет не справляться, то стоит выключить KeepAlive и размышлять о кешировании.

$ sudo vim /opt/local/apache2/conf/extra/httpd-default.conf
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
UseCanonicalName Off
AccessFileName .htaccess
ServerTokens Prod
ServerSignature Off
HostnameLookups Off

В httpd-vhosts.conf описываются виртуальные хосты. Я это делаю так:

$ sudo vim /opt/local/apache2/conf/extra/httpd-vhosts.conf
NameVirtualHost *:80
<VirtualHost *:80>
    ServerAdmin webmaster@theapplegeek.ru
    ServerName theapplegeek.ru
    ErrorLog "logs/theapplegeek.ru-error_log"
    CustomLog "logs/theapplegeek.ru-access_log" common
    DocumentRoot "/Users/ctrld/Sites/theapplegeek/public_html"
    <Directory "/Users/ctrld/Sites/theapplegeek/public_html">
        Options FollowSymLinks -Indexes
        AllowOverride All
        Order allow,deny
        Allow from all
     </Directory>

    <Location "/wp-content/uploads">
        php_admin_flag engine off
        AddType text/plain .html .htm .shtml
    </Location>
</VirtualHost>

<VirtualHost *:80>
    ServerName          www.theapplegeek.ru
    RedirectPermanent   /   "http://theapplegeek.ru/"
</VirtualHost>

Обратите внимание на запрет php для /wp-content/uploads. Также вы видите, что основное имя хоста у меня без www – этот рудимент меня удивлял ещё лет семь назад. Но так как есть некоторые посетители, пытающиеся вводить www, то переучивать их можно только с помощью Permanent Redirect на основной домен.

Всё, Apache сконфигурирован. Конечно же, путь /Users/ctrld/Sites/theapplegeek/public_html должен существовать. Делаем тестовый файл для проверки php:

$ vim /Users/ctrld/Sites/theapplegeek/public_html/info.php
<?php
    phpinfo();
?>

Проверим конфигурацию apache:

$ sudo /opt/local/apache2/bin/apachectl configtest
Syntax OK

Если всё в порядке, то запускаем его (в первый раз – через launchctl load -w, чтобы он смог стартовать после перезапуска системы):

$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

А в дальнейшем можем использовать apachectl:

$ sudo apachectl start
$ sudo apachectl stop
$ sudo apachectl restart
$ sudo apachectl graceful

Последняя команда (graceful) позволяет рестартовать apache без обрыва соединений, что вежливо по отношению к посетителям.

Можно убедиться, что apache запущен:

$ ps ax | grep htt
37877   ??  Ss     0:00.10 /opt/local/apache2/bin/httpd -k start
37878   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start
37879   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start
37880   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start
37881   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start
37882   ??  S      0:00.00 /opt/local/apache2/bin/httpd -k start

Теперь небольшой “хинт”. Я описал виртуальный хост реального сайта theapplegeek.ru. Но я ещё ничего не переносил и контента там нет. Для того, чтобы оттестировать сайт и исправить ошибки, я направляю запросы на новое место, модифицируя /etc/hosts на том компьютере, с которого я тестирую сайт, но другие посетители будут ходить до переключения в DNS на старое место.

$ sudo vim /etc/hosts
94.45.55.146	theapplegeek.ru
94.45.55.146	www.theapplegeek.ru

Всё, подготовительные работы сделаны, можно проверять. Открываю в браузере URL http://theapplegeek.ru/info.php с тестовым скриптом PHP. Всё работает. Благодать. Если же есть какие-то проблемы, то нужно смотреть логи:

$ tail -f /opt/local/apache2/logs/theapplegeek.ru-error_log
$ tail -f /opt/local/apache2/logs/theapplegeek.ru-access_log
$ tail -f /opt/local/apache2/logs/error_log
$ tail -f /var/log/php_errors.log

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

Домашняя сеть у меня подключена через TimeCapsule, и проброс обращений извне к web-серверу, находящемся на адресе 192.168.98.2, я сделал через Port Mapping:

Внешний адрес я обычно смотрю через сервис WhatIsMyIP (94.45.55.146). Как только я перенёс сайт и проверил его работу, я зашёл в панель управления моими DNS-зонами и переключил записи со старого места на новое:

И затем начал следить за логами и корректировать проблемы, которые я пропустил. На помощь приходит в том числе такая конструкция, позволяющая искать 404/etc:

$ tail -1000 /opt/local/apache2/logs/theapplegeek.ru-access_log \
	| awk '$9 != 200 && $9 != 304 {print $9, $7}' | sort | uniq -c

Вуаля.

Через несколько часов убираем из /etc/hosts добавленные ранее записи.

Следующим шагом я сконфигурирую nginx с использованием fastcgi для обработки PHP. Ещё (это больше памятка самому себе) нужно будет включить ежедневную ротацию логов. И сделать тюнинг PHP и сетевых параметров Mac OS X.

Недавно я подключился к провайдеру Интернет по Ethernet, да ещё с постоянным IP-адресом. Сервер, на котором у меня расположен сайт, периодически ведёт себя очень странно, я думаю, что вы могли это заметить. Иногда сервер перестаёт отвечать, я подозреваю вываливание в Kernel Panic (на сервере стоит FreeBSD 6.3). Подозреваю аппаратную проблему, но заменить сервер я пока не могу, а обновить систему до 8.0, или установить Linux можно, но непросто, так как я использую для сайтов jail’ы. В итоге я решил временно перенести сайты на MacBook, который у меня используется в виде сервера.

Подъём сервера для хостинга WordPress состоит из нескольких этапов, и я рассмотрю их в серии статей. В этой части я опишу установку MySQL, затем – настройку web-сервера на базе nginx с использованием PHP в виде Fastcgi (можно было бы использовать и Apache, но мне нужен легковесный и быстрый web-сервер, хорошо работающий под большой нагрузкой). Итак, приступим.

Поставить MySQL под Mac OS X можно несколькими методами. Самый неинтересный для меня – это MAMP (готовое решение, включающее MySQL, Apache, PHP с полным набором модулей). Объяснять почему мне это не нравится не буду, и так понятно.

Второй – из бинарного пакета с сайта MySQL (выбираем версию MySQL 5.1—Generally Available (GA) release for production use). Вот более короткий линк к нужному пакету, я ставлю из package format, Mac OS X 10.5 (x86_64), весь процесс описан в документации. Во многих случаях этот способ предпочтительный, так как MySQL здесь собран гарантированно нормально. Но есть некоторая сложность в обновлении – я предполагаю, что автообновлений нет, и придётся устанавливать новые версии вручную.

Третий метод, привычный для большинства системных администраторов Unix – это использование пакетного менеджера MacPorts, мне он нравится из-за предсказуемости обновлений, да и в любом случае мне понадобятся порты для дальнейших шагов по запуску сайта.

Есть, конечно же, и четвёртый метод, заключающийся в компиляции MySQL из исходных текстов с накладыванием различных патчей, оптимизирующих работу MySQL, но я не любитель стиля Gentoo, и мне важнее предсказуемость работы системы и простота обновлений, чем выигрыш производительности на 15%.

Сначала нужно поставить XCode, в котором находятся средства разработки под Unix, необходимые для компиляции MySQL и других пакетов. Это просто, объяснять не буду.

Потом – MacPorts. Списывается пакет последней версии под нужную версию Mac OS X, в моём случае MacPorts-1.8.2-10.6-SnowLeopard.dmg, и устанавливается. Сразу же обновим дерево портов:

$ . ~/.profile
$ sudo port selfupdate

Ставим MySQL Server (на MacBook 2.2 GHz пакет поставился за 22 минуты):

$ sudo port install mysql5-server

При установке выдалось сообщение о том, как установить файлы базы данных и как запустить mysql. Выполняем:

$ sudo -u _mysql mysql_install_db5
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

Проверим, что MySQL запустился:

$ ps ax | grep mysql | grep -v grep
 2050   ??  Ss     0:00.00 /opt/local/bin/daemondo --label=mysql5 --start-cmd /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper restart ; --pid=none
 2060   ??  S      0:00.02 /bin/sh /opt/local/lib/mysql5/bin/mysqld_safe --datadir=/opt/local/var/db/mysql5 --pid-file=/opt/local/var/db/mysql5/ceiling-cat.local.pid
 2110   ??  S      0:00.07 /opt/local/libexec/mysqld --basedir=/opt/local --datadir=/opt/local/var/db/mysql5 --user=_mysql --log-error=/opt/local/var/db/mysql5/ceiling-cat.local.err --pid-file=/opt/local/var/db/mysql5/ceiling-cat.local.pid

Я привык к именам программ вида mysqladmin и mysql, а в каталоге /opt/local/bin описаны симлинки вида mysqladmin5/mysql5. Можно сделать нужные симлинки, но я сделаю универсальнее, прописав путь к нужным утилитам без суффикса “5″. Путь после модификации должен быть таков:

$ vim ~/.profile
export PATH=/opt/local/lib/mysql5/bin:/opt/local/bin:/opt/local/sbin:$PATH

Перечитываем путь с помощью “source”:

$ . ~/.profile
$ echo $PATH
/opt/local/lib/mysql5/bin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

Теперь можем привычно запускать утилиты MySQL

$ which mysql
/opt/local/lib/mysql5/bin/mysql

Проверить, запустился ли MySQL, можно и так:

$ mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.1.42 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Сразу же устанавливаем пароль root (этот пароль я сразу же после написания статьи изменю):

$ mysqladmin -u root password 'fc97a2060ec0775ed3b6aa011ee27e88'

Для того, чтобы не вводить пароль каждый раз, прописываем его в конфиг-файле:

$ touch ~/.my.cnf
$ chmod 600 ~/.my.cnf
$ vim ~/.my.cnf
[mysql]
user    =   root
pass    =   fc97a2060ec0775ed3b6aa011ee27e88

Обязательно нужно или поменять пароль для доступа через сеть, или удалить записи для хостов “hostname.local” и 127.0.0.1. Когда мне понадобится, я создам нужных пользователей, поэтому буду удалять.

$ mysql mysql
mysql> select Host, User, Password from user where user = 'root';
+-------------------+------+-------------------------------------------+
| Host              | User | Password                                  |
+-------------------+------+-------------------------------------------+
| localhost         | root | *769F25A82BD5CC256FA4D47499CE6026D89D72E6 |
| ceiling-cat.local | root |                                           |
| 127.0.0.1         | root |                                           |
+-------------------+------+-------------------------------------------+
mysql> delete from user where User = "root" and Host = "127.0.0.1";
Query OK, 1 row affected (0.00 sec)

mysql> delete from user where User = "root" and Host = "ceiling-cat.local";
Query OK, 1 row affected (0.00 sec)

mysql> select Host, User, Password from user where user = 'root';
+-----------+------+-------------------------------------------+
| Host      | User | Password                                  |
+-----------+------+-------------------------------------------+
| localhost | root | *769F25A82BD5CC256FA4D47499CE6026D89D72E6 |
+-----------+------+-------------------------------------------+

Можно было бы на этом и закончить, но лучше донастроить MySQL через конфиг-файл /etc/my.cnf. По крайней мере нужно выставить использование по умолчанию UTF8, включить INNODB, ограничить количество коннектов, и включить slow_query_log.

Примеры конфиг-файлов поставляются вместе с MySQL:

$ ls -al /opt/local/share/mysql5/mysql/my*cnf
-rw-r--r--  2 root  admin   4851 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-huge.cnf
-rw-r--r--  2 root  admin  20232 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-innodb-heavy-4G.cnf
-rw-r--r--  2 root  admin   4825 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-large.cnf
-rw-r--r--  2 root  admin   4836 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-medium.cnf
-rw-r--r--  2 root  admin   2474 Jan  7 22:26 /opt/local/share/mysql5/mysql/my-small.cnf

Меня устраивает конфигурация medium:

$ head -5 /opt/local/share/mysql5/mysql/my-medium.cnf
# Example MySQL config file for medium systems.
#
# This is for a system with little memory (32M - 64M) where MySQL plays
# an important part, or systems up to 128M where MySQL is used together with
# other programs (such as a web server)

Копирую её в /etc/my.cnf:

$ sudo cp /opt/local/share/mysql5/mysql/my-medium.cnf /etc/my.cnf

Корректирую конфиг (если интересно, то одна из первых версий доступна для списывания):

• Отключаю возможность доступа по сети: skip-networking
• Выставляю везде default-character-set=utf8
• Для mysqld включаю character-set-server = utf8 и default-character-set = utf8
• Ограничиваю количество сессий max_connections=50
• thread_cache_size = 16
• query_cache_size = 32M
• Включаю секцию innodb
• Выставляю логгирование (slow_query_log = 1, slow_query_log_file = /var/log/mysql-slow.log, log-error = /var/log/mysql.log)

Создаю нужные файлы логов, иначе они не воспримутся:

$ sudo touch /var/log/mysql-slow.log
$ sudo chown _mysql:_mysql /var/log/mysql-slow.log
$ sudo touch /var/log/mysql.log
$ sudo chown _mysql:_mysql /var/log/mysql.log

Перезагружаем сервер MySQL (-w отключает disable, т.е. MySQL загрузится при рестарте системы)

$ sudo launchctl unload -w /Library/LaunchDaemons/org.macports.mysql5.plist
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

Нужно посмотреть лог на предмет ошибок или проблем:

$ tail -100 /var/log/mysql.log

Очень важно сделать базовый аудит конфигурации MySQL, для этого я использую два скрипта. Первый – mysqltuner.pl:

$ curl http://mysqltuner.com/mysqltuner.pl -o mysqltuner.pl
$ chmod +x mysqltuner.pl
$ ./mysqltuner.pl

Второй – mysql-tuning-primer:

$ curl http://launchpadlibrarian.net/36004840/tuning-primer.sh -o tuning-primer.sh
$ chmod +x tuning-primer.sh
$ ./tuning-primer.sh

Особых проблем скрипты не выявили. Если бы нашли, то нужно было бы подправить /etc/my.cnf и перезапустить MySQL.

Настройка закончена, осталось перезапустить Mac OS X для проверки, подымется ли MySQL после рестарта. У меня он поднялся.

Если вы хотите углубить свои знания по MySQL, то рекомендую ознакомиться с сайтом MySQL Performance Blog (этот сайт ведут специалисты широкоизвестной в узких кругах фирмы Percona).

Использование GUI для работы с базой данных

Я не разработчик, и мне хватает командно-строковой утилиты mysql. Но если вам нужен GUI, то можно будет или поставить phpMyAdmin (он будет доступен через web), или же утилиту под Mac OS X Sequel Pro (она бесплатная, приветствуются пожертвования).

Sequel Pro мне нравится тем, что он позволяет соединяться через туннель SSH, и на хосте с MySQL достаточно открыть сетевой доступ через 127.0.0.1. Для того, чтобы это сделать, нужно в /etc/my.cnf закомментировать опцию “skip-networking” (конечно же, после этого нужно перезагрузить MySQL) и открыть доступ пользователю (например, root):

$ mysql mysql
mysql> GRANT ALL ON *.* TO root@127.0.0.1 IDENTIFIED BY 'fc97a2060ec0775ed3b6aa011ee27e88';
mysql> FLUSH PRIVILEGES;

Настройка туннелирования:

Интерфейс программы:

Проверка производительности MySQL

Для того, чтобы знать, какую нагрузку выдержит MySQL, можно применить бенчмаркинг sql-bench (это необязательно, раздел можно пропустить). К сожалению, в портах его я не нашёл, поэтому сделаю не совсем правильно, но действенно – поставлю бинарный package с сайта MySQL (это второй описанный метод), но не буду запускать сам MySQL.

Списываю package Mac OS X 10.5 (x86_64) и устанавливаю его (только mysql-…..pkg, ни в коем случае не prefpane и не StartupItems). Система поставилась в /usr/local/mysql (это симлинк на каталог с установленной версией типа mysql-5.1.42-osx10.5-x86_64).

SQL-Bench использует Perl, для соединения с MySQL нужен DBD::mysql, поставим его (в ответ на предложение сконфигурировать CPAN нажимаем Enter или пишем “yes”):

$ sudo perl -MCPAN -eshell
Would you like me to configure as much as possible automatically? [yes] yes
cpan[1]> install DBD::mysql
...
 CAPTTOFU/DBD-mysql-4.013.tar.gz
 /usr/bin/make install  -- OK
cpan[2]> quit

Запускаем бенчмаркинг. Сразу предупреждаю, что процесс длительный, у меня он занял 16 минут:

$ cd /usr/local/mysql/sql-bench/
$ sudo ./run-all-tests --server=mysql --user=root -pass=fc97a2060ec0775ed3b6aa011ee27e88 --log

Смотрим на результат, размышляем.

На этом заканчиваем, в следующей части приступим к настройке web-сервера.

Замена паролей

При необходимости меняем пароль (как я и обещал, я это сделал – лучше три лишние команды, чем потеря данных):

$ mysql mysql
mysql> GRANT ALL ON *.* TO root@127.0.0.1 IDENTIFIED BY 'verysecretpassword';
mysql> GRANT ALL ON *.* TO root@localhost IDENTIFIED BY 'verysecretpassword';
mysql> FLUSH PRIVILEGES;