Оптимизация WordPress, W3 Total Cache и иже с ней

Ускоряемся, или любой каприз за ваши деньги.

Если блог начинает приносить некоторый доход, то стоит подумать о том, чтобы вложить денег в развитие оного. Это, во-первых, поисковая оптимизация, и во-вторых, производительность. О поисковой оптимизации можно говорить долго, да это и не основная тема данной статьи. А вот о такой важной вещи, как оптимизация производительности поговорить стоит. Бюджетные хостинги предоставляют только самый минимум возможностей, и даже несмотря на хвалёную гибкость такого дешёвого хостинга как джино — они не позволяют повысить квоты на процессорное время и занимаемую память — стратегический ресурс, хуле. Таким образом, при росте нагрузки на сайт имеет смысл задуматься о смене хостинга на более отвечающий вашим чаяниям, либо о переходе на другой тариф. При выборе хостинга следует обращать внимание не столько на размер диска, который вам обещают, и поддержку всяких наворотов (кроме некоторых), сколько на квоты по используемой оперативке, времени процессора, типу установленного процессора. Вообще, внимание на железо хостера надо обратить самое тщательнейшее, равно как и на квоты по его использованию, причем в соотношении цена/качество. Также нужен минимальный канал в 100 Мбит/с — синхронный. Когда купите хостинг — обязательно протестируйте реальную скорость загрузки контента (делается просто — заливается на хост файл в 200-300 МБ, а затем, с компьютера у которого соединение сопоставимо (или с нескольких — если 100 Мбит у вас нет) загружайте данный файл. И посмотрите — нет ли «провисаний» канала, когда скорость резко падает. Что неясно — задать вопрос в отдел продаж, а также почитать отзывы в сети, на тему опыта использования услуг хостинг-провайдера этого, при настройке хостинга и первоначальном «въезжании» в вопрос — полезно давать понять техподдержке, что вы живы, и способны добиваться исправления тех или иных проблем, причем делать это надо не по системе заявок (там заявки по несколько дней могут висеть), а по телефону. Но отзывы это уже вторично. Между прочим — если знаете более-менее английский, то рекомендую обратить внимание как раз на западный хостинг. Хостмонстр, дримхост, или иной из этой же группы. При более чем приемлемых ценах они предлагают хорошие услуги. Замечено, западный хостинг по соотношению цена/качество — значительно лучше практически любого хостинга на территории СНГ. Так что единственные конкурентные преимущества у СНГ-шников — это языковой барьер между поставщиком услуги и её конечным пользователем. Думается мне, если тот же дримхост или хостмонстр вдруг переведёт интерфейс сайта, условий использования, инструкции по оплате и язык панели управления на русский — он похоронит и агавников, и мастерхостовцев, а если и не похоронит, то здорово откусит у них кусок рынка.

В идеале, конечно, это VPS а ещё лучше (и дороже) VDS. Стоит это удовольствие от 30-35 баксов в месяц за минимальную конфигурацию в VPS, ну а VDS — там уже на сотни долларов идут суммы. Реально VPS за 50 баксов способен справиться с довольно высокими нагрузками, не роняя ресурс — при этом даже без кэширования и оптимизации среды исполнения. Но, на VPS есть как правило доступ по SSH, и возможность доустановки требуемого ПО. Этим просто грех не пользоваться. Если у вас там есть хотя бы 512 МБ оперативки — надо сделать кэширование в памяти, кроме того, если есть знания — можно ставить не тяжёленький апач, а более лёгкий nginx или lighthttpd. Правда, большой вопрос, как они будут себя вести в обращении с .htaccess файлами конфигурации хостов. Лично я бы оставил Apache, вы же можете настроить систему по своему вкусу.

Кроме того, очень стоит установить и правильно настроить какой-либо оптимизатор, вроде eAccelerator (и между прочим более-менее подробный мануал по этому можно найти здесь). Единственное, что могу добавить, это всё-таки подправить параметры указанные в том руководстве в соответствии с реальным размером оперативки на вашем VPS. В частности, если оной 512 и выше — стоит, во-первых, задать энный размер кэша для байт-кода В ПАМЯТИ, изменением параметра eaccelerator.shm_max=»256″ — вместо 256 впишите то, что считаете нужным, это позволит немного уменьшить задержку в генерации страницы на дисковых операциях ввода-вывода. По желанию, можно вообще отказаться от дискового кэша, и выставить параметр eaccelerator.shm_only=»1″ в единичку (по-умолчанию там «0»), тогда eAccelerator вообще не будет использовать диск, но при этом вам стоит хорошенько протестировать систему на возможные «глюки». Плюс, раскомментировать строки:

eaccelerator.keys = «shm»
eaccelerator.sessions = «shm»
eaccelerator.content = «shm»

Убрав символ «#» в начале каждой. Перезапустите httpd ( #service httpd restart, или что там у вас будет). В целом, я не уверен, что после этого имеет смысл ставить Memcached — но вы можете это сделать, хотя бы в порядке эксперимента, ведь W3 Total Cache позволяет хранить в ней статический контент, а значит польза в любом случае должна быть.

Неплохо, для совсем уж кошерной оптимизации, допилить MySQL (если ваш проект использует именно эту БД). А именно, в настройках /etc/my.conf или /etc/mysql/my.conf — зависит от дистрибутива — выставить требуемые параметры:

key_buffer_size = 32M
table_cache = 256
record_buffer = 1M
max_connections = 650
sort_buffer_size = 32M
query_cache_limit = 2M
query_cache_size = 64M
query_cache_type = 1

Как утверждает источник сего — данные параметры подходят к оптимизации для сервера с оперативкой в размере 384 МБ ОЗУ. После сохранения конфигурации делаем #service mysqld restart — в смысле перезапускаем службу MySQL и наслаждаемся полученным результатом.

В целом, более-менее понятный и простой мануал по переезду на VPS есть на сайте производителя некой CMS-ки, под названием HostCMS. Никогда не пользовался, но мануал вроде ничего, взять его полностью можно здесь.

Как несложно увидеть, оптимизация любого приложения — процесс сложный и творческий. Помимо сказанного, я бы рекомендовал произвести тестирование ресурса под нагрузкой с помощью таких пакетов как Jakarta Meter, проанализировать логи загрузки на железо — их зависимость от нагрузки, определить моменты, когда сервер начинает «захлёбываться». Думаю, внимательный читатель заметил, что в статье был упомянут Google Page Speed, но нигде не описано как им пользоваться. Это сделано намеренно, ибо инструмент достаточно прост. Там есть нечто вроде Speed Rank, изменяющегося от 0 до 100. Среднее значение этого блога до оптимизации плагином составило 65 пунктов. После исправления в соответствии с советами этого дополнения (да он советы даёт) — цифирка подросла до 76 пунктов — немного, а приятно. Работает это дополнение на вкладке в FireBug. Но моё вам предостережение — не гонитесь за оценкой, всё равно в 100 баллов вряд ли уложитесь — у главной страницы Google 89 — а нервы потреплете. Вообще, оценочная зависимость это случай тяжёлый, правда тема другого разговора, уже на темы психологии, но и здесь имеет место — не гонитесь за лишней единичкой в этом рейтинге, вполне достаточно, если скорость загрузки страницы до момента её рендеринга браузером будет 2 — 3 секунды на соединении в мегабит.

Кроме того, к проблеме выбора тарифного плана и типа хостинга надо подходить не с позиций максимального быстродействия (так никаких денег не хватит), а с точки зрения того, каково соотношение цена/качество, и покрывается ли цена доходом от блога/сайта. Как минимум эти положения должны выполняться, т.е. достигаться некое равновесие между доходом и расходом. Не стоит замыкаться на русских — СНГ-шных хостинг-провайдерах. Помимо прочего — не забывайте о юридических аспектах использования хостинга — обязательно внимательно и с «увеличительным стеклом» читайте оферту, или иную форму договора, а особенно — всякие «мелкие шрифты» и сноски, ссылки на нормативные документы — надо читать документы. В частности — обратите внимание на гарантированный аптайм и регламентацию времени неработоспособности — начиная с какого количества часов, в течении которых сервер «лежал», вы имеете право на компенсацию или иное возмещение убытков, какова скорость реагирования техподдержки на заявки — если этого нет в договоре, уточните в отделе продаж. В этом смысле русский хостинг выгоднее тем, что чтобы привлечь к ответственности согласно заключённому договору — ни ему ни вам ходить далеко не надо. Да и в техподдержку звонить получается дешевле.

Таким образом, мы рассмотрели не только некоторые моменты по оптимизации WordPress, но и затронули тему настройки исполняющей среды, вопросы выбора хостинга и прочего. Надеюсь, вам этот материал был полезен. Как обычно — перепечатка разрешена, но с сохранением ссылки :) О замеченных неточностях и огрешностях — всенепременно сообщайте, исправлю.

Автор

Алекс Разгибалов

Сумасшедший мужчина, неопределённого возраста, наслаждающийся манией преследования. Паталогически недоверчив, эгоистичен, авторитарен. Вторичные диагнозы - программист и поц. Владеет английским языком на уровне около хренового разговорного. Также знаком с некоторыми другими языками. Интересуется всем и вся, за счёт чего в любой области знания являются поверхностными, неглубокими. Характер невыдержанный. Крепость - 55 градусов.

Оптимизация WordPress, W3 Total Cache и иже с ней: 5 комментариев

  1. Поставил на свой сайт W3 Total Cache http://www.benatar.ru. Хорошая вещь. На хостинге есть memcache — я туда кэширую запросы и объекты (кстати, что за объекты, так пока и не понял; но их много и кэшируются они хорошо). Страницы — на диск, ибо memcache у ht-systems маловат — 256 Мб на весь сервер.
    А вот бесплатных CDN в списке настроек, судя по всему, нет.
    Но я нашел один — http://www.coralcdn.org Сервер кэширования — имя_вашего_сайта.доменная_зона.nyud.net — нужно прописать в настройках кэша, а тип кэширования выбрать mirror. У меня уже частично заработало (файлы темы через CDN грузятся), посмотрю, даст ли какой-нибудь прирост.

    1. Вообще CDN сети предназначены для доставки контента с ближайшего к пользователю сервера. Я вот просто не уверен, что бесплатный сервис способен предоставить такую инфраструктуру.
      Да и в целом, как в моём случае оказалось, данный плагин увеличивал нагрузку на сервер во много раз (и время отклика тоже). Т.е. не ускорял, а наоборот, замедлял отдачу. Я подозреваю, это происходило из-за того, что он оптимизирован всё же для использования на VPS/VDS а не на shared-хостинге.

  2. Итак, CDN показала свою работоспособность по отношению к файлам больше 500 кБ. Но увы, все ее сервера находятся за бугром, потому бывают недоступны в наших краях. Пришлось отключить, а жаль — идея мне очень понравилась.
    Насчет нагрузки — у меня тоже не VDS, но скорость ощутимо подросла. Может быть стоило покопаться в настройках? Благо там их очень много, и некоторые на шаровом хостинге действительно будут только замедлять работу.

    1. Копался, причем активно и очень длительное время :) Нет, в принципе я вот задумываюсь со временем перейти на VPS или даже что-то посерьёзнее… Если финансы будут позволять :) В принципе, аренда collocation позволяет размещать свой сервер на площадке провайдера где-то за 2400-2500 т.р./мес. Естественно при этом получается хостинг абсолютно иного уровня и по надёжности и по быстродействию. Ну и лезвие 1U само по себе стоит где-то 30к, в среднем — такая сборочка включает в себя примерно двух-четырёхъядерный проц интел, 4-6 ГБ оперативки, 100 МБит сеть и 500-1000 Гб дискового пространства. Естественно, на хосте такого рода должен работать не один проект :) Как минимум какой-либо ресурс, который будет выводить в ноль стоимость аренды и понемногу окупать железо. А так, данная конфигурация позволяет очень и очень неплохую систему создать, с блэкджеком и шлюхами memcached, APC и nginx. Ну и хостинг нескольких доменов.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Собирать идеально - не обязательно, просто приблизительно соберите картинку (должен быть включен JavaScript).WordPress CAPTCHA