Взгляд на современный серверный стек WordPress

Вы помните, когда вы могли запустить «быстрый» веб-сайт WordPress, используя только сервер Apache и PHP? Да, это были дни! Тогда все было намного проще.

Теперь все должно загружаться молниеносно! Посетители не имеют таких же ожиданий относительно времени загрузки, как раньше. Медленный веб-сайт может иметь серьезные последствия для вас или вашего клиента.

Дальнейшее чтение на SmashingMag:

• Правильные разрешения и права собственности на файловую систему WordPress
• Перемещение сайта WordPress без проблем
• Как разрабатывать WordPress локально с помощью MAMP
• Методы кэширования своими руками с помощью WordPress

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

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

Обзор

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

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

• цикл запрос-ответ между браузером и WordPress;
• WordPress (который представляет собой скрипт, выполняемый средой выполнения PHP);
• цикл запроса-результата между WordPress и базой данных MySQL.

Роль современного стека серверов WordPress заключается в оптимизации этих трех областей. Благодаря этим оптимизациям все загружается быстрее. И самое приятное, что есть несколько способов сделать это. (Ура!)

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

Цикл запроса-ответа

Все начинается с браузера. Допустим, вы хотите просмотреть домашнюю страницу modern.wordpress-stack.org . Ваш браузер начнет работу с отправки HTTP-запроса на веб-сервер, на котором он размещен. На другом конце веб-сервер примет ваш запрос и превратит его в HTTP-ответ.

Первым ответом всегда должен быть HTML-контент домашней страницы modern.wordpress-stack.org (если нет ошибки). Однако работа вашего браузера еще не сделана. Нет, этой домашней странице по-прежнему нужны дополнительные файлы, наиболее распространенными из которых являются файлы CSS, JavaScript и файлы изображений.

Таким образом, браузер будет отправлять запросы на эти файлы. Веб-сервер ответит запрошенными файлами (опять же, если ошибок нет). Этот цикл будет продолжаться до тех пор, пока в браузере не будет достаточно информации для отображения домашней страницы. Чем быстрее происходит этот цикл, тем быстрее будет загружаться веб-сайт.

Это очевидное упрощение, но именно так все работает на большинстве веб-сайтов WordPress.

Оптимизация цикла запрос-ответ

Хорошо, это подводит нас к очевидному вопросу: как заставить веб-сервер выполнять этот цикл быстрее? Это отличный вопрос, и он является одной из причин существования современного стека серверов WordPress.

Стек существует, потому что вы не можете просто сделать веб-сервер быстрее. Веб-сервер также является диспетчером. Он может получить запрос и просто переслать его другим службам.

Эти другие службы часто являются узким местом в этом цикле запроса-ответа. В WordPress этим узким местом является PHP, поэтому оптимизация цикла запрос-ответ сводится к двум вещам. Мы хотим, чтобы веб-сервер:

• получать как можно меньше запросов,
• пересылать как можно меньше запросов к PHP.

Современный стек серверов WordPress фокусируется на последнем. Он хочет перенаправить как можно меньше запросов к PHP. Это будет основной целью оптимизации стека.

Мы сосредоточимся на второй цели, потому что стек мало что может сделать с первой; это не оказывает на него прямого влияния. Второй решается либо конфигурацией веб-сервера, либо современными методами разработки.

Элементы стека для цикла запрос-ответ

Итак, какие элементы стека помогут нам сократить количество запросов, пересылаемых в PHP? Ну, в частности, два элемента стека помогут нам достичь этой цели: веб-сервер и кэш HTTP.

Веб сервер

Мы уже довольно много говорили о веб-серверах. В пространстве веб-серверов есть три крупных игрока:

• Апачи
• Информационные службы Интернета (IIS)
• нгинкс

Вместе они составляют более 90% доли рынка веб-серверов в Интернете. Мы собираемся сосредоточиться на Apache и nginx. Хотя IIS можно использовать для запуска WordPress, он не распространен, поскольку доступен только для Windows, а большинство серверов WordPress используют Linux.

Это оставляет нас с Apache и nginx. На протяжении всей жизни WordPress Apache был рекомендуемым веб-сервером. У нас был стек LAMP (Linux, Apache, MySQL и PHP), который запускал WordPress как на компьютере, так и на сервере.

Но за кулисами все изменилось. В городе появился новый игрок, и его имя было nginx. Automattic и WordPress.com используют его с 2008 года. Это веб-сервер, на котором работает самый большой процент веб-сайтов с высоким трафиком (многие из которых работают на WordPress). Вот почему многие высококлассные хостинговые компании и ведущие агентства WordPress используют его в качестве своего веб-сервера.

Дело не в том, что Apache — плохой веб-сервер. Есть специалисты по Apache, которые могут заставить его отлично работать при большом трафике. Это просто не так хорошо работает из коробки или со стандартной конфигурацией WordPress.

Между тем, единственная цель nginx — обрабатывать большой трафик. Именно поэтому Игорь Сысоев начал проект, когда работал в Рамблере.

Одна из причин, по которой nginx лучше обрабатывает больше трафика, заключается в том, что он использует FastCGI для связи с PHP. Что такое FastCGI? Это протокол, который позволяет PHP работать как служба отдельно от веб-сервера.

Apache не делает этого по умолчанию. Каждый раз, когда веб-сервер получает запрос, ему необходимо запустить процесс выполнения PHP — даже для изображений, JavaScript и CSS. Это уменьшает количество запросов, которые может обработать сервер, и скорость их обработки.

Это противоречит одной из целей современного стека серверов WordPress, которую мы видели ранее. Стек должен поддерживать время цикла запрос-ответ как можно меньше. Загрузка PHP для каждого запроса, даже если он не нужен, противоречит этой цели. Итак, если вы используете Apache, загляните в FastCGI.

HTTP/2 — еще одна важная функция веб-сервера, о которой вам следует знать. Это следующая версия HTTP, протокола, на котором основан весь наш цикл «запрос-ответ».

До появления HTTP/2 браузер мог иметь только шесть подключений к веб-серверу. И каждое соединение могло обрабатывать только один запрос за раз. Таким образом, на практике цикл запроса-ответа ограничивался шестью запросами за цикл.

Это настоящая проблема. Большинство веб-сайтов имеют десятки запросов в своем цикле. Разработчики и системные администраторы нашли хитрые способы обойти это ограничение.

Одним из наиболее известных обходных путей является практика объединения файлов CSS и JavaScript. В идеальном сценарии это сократит общее количество запросов файлов CSS и JavaScript до двух: один для JavaScript и один для CSS.

Это не обязательно с HTTP/2. HTTP/2 допускает неограниченное количество запросов на одно соединение. Это позволяет выполнять все дополнительные запросы после исходного HTML-ответа одновременно.

Это имеет огромное значение для производительности. Большая часть работы по оптимизации серверного стека сосредоточена на цикле запрос-ответ. Сократив количество циклов до нескольких, HTTP/2 проделал за нас огромную работу.

HTTP-кэш

Наиболее важной частью современного стека серверов WordPress является кэш HTTP. В мире WordPress мы также называем это кэшированием страниц. Цель кэша HTTP — кэшировать ответы на запросы. Что это значит?

Что ж, давайте вернемся к нашему предыдущему примеру. Браузер отправляет запрос на домашнюю страницу modern.wordpress-stack.org , а веб-сервер получает этот запрос и перенаправляет его в PHP.

Проблема с этим сценарием в том, что веб-сервер тупой. Он всегда будет перенаправлять все запросы, которые он получает, в PHP, независимо от того, будет ли большинство запросов генерировать один и тот же ответ.

Это именно то, что происходит, когда посетители не вошли в систему. Для веб-сервера все это разные запросы, но ему все равно. Он перенаправит их все в PHP, который будет генерировать одинаковый ответ для всех из них.

Это ужасно! Как мы видели ранее, PHP является настоящим узким местом в нашем цикле запрос-ответ. Ваш браузер не может отправлять последующие запросы, пока не получит первоначальный ответ домашней страницы. Мы не можем заставить веб-сервер пересылать все на PHP по умолчанию.

Вот тут-то и появляется кеш HTTP. Он находится между веб-сервером и PHP. Его работа заключается в проверке каждого запроса, который получает веб-сервер, и поиске кэшированного ответа. Если их нет, он перенаправит запрос в PHP, а затем кэширует ответ, который генерирует PHP.

Это значительно сокращает время цикла «запрос-ответ», ускоряя загрузку веб-сайта. Это также позволяет веб-серверу обрабатывать больше одновременных запросов без перебоев.

Различные варианты кэширования HTTP

В этот момент вы должны задаться вопросом: «Как я могу получить этого ребенка на моем сервере как можно скорее ?!» Хорошая новость заключается в том, что установить HTTP-кеш на сервер WordPress довольно просто. Это компонент с самым широким набором опций.

Установите плагин для кэширования страниц

Самый простой способ — установить плагин для кэширования страниц. У вас есть несколько вариантов на выбор:

• Пакетный кэш
• Гиперкэш
• Активатор кэша
• WP Ракета
• WP Супер Кэш
• Общий кэш W3

Все, кроме WP Rocket, доступны в виде бесплатных плагинов в каталоге WordPress. Таким образом, вы можете установить его и сразу же протестировать. При этом из четырех плагинов лучшим является WP Rocket. Хотя это платный плагин, он делает гораздо больше, чем просто создает кэш HTTP. Эти другие преимущества увеличивают работу, которую выполняет кэш HTTP.

Как работает плагин кэширования страниц?

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

Во-первых, файл advanced-cache.php должен находиться в папке wp-content . Это настоящий файл. Но в отличие от большинства плагинов WordPress, этот не срабатывает по умолчанию. WordPress также необходимо, чтобы константа WP_CACHE была true , чтобы загружать выпадающее меню. В большинстве случаев вы должны установить это в wp-config.php .

На приведенной выше диаграмме показано, что происходит, когда вы включаете вставку с подключаемым модулем кэширования. WordPress загружает вставку в wp-settings.php в процессе загрузки. Это достаточно рано в процессе, так что WordPress еще не сделал ничего трудоемкого.

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

Итак, буферизация вывода — интересная система. Что он делает, так это фиксирует все выходные данные PHP-скрипта в строковой переменной до тех пор, пока не произойдет одно из двух:

• вы указываете PHP прекратить буферизацию вывода с помощью одной из встроенных функций,
• скрипт PHP завершает работу и должен вернуть ответ браузеру.

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

Попросите веб-сервер сделать это

Следующий вариант — добавить кэш HTTP на уровне веб-сервера. Это работает так, что веб-сервер кэширует все ответы на запросы, которые перенаправляются в PHP. Это решение лучше, чем кеширующий плагин, потому что ему вообще не нужно касаться PHP.

Диаграмма выше дает обзор того, что происходит на веб-сервере. Веб-сервер получает запрос и сверяется с кэшем HTTP. Если ответ уже был кэширован, кэш HTTP отправит его обратно.

В противном случае он перенаправит запрос модулю PHP (обычно FastCGI). Он передаст запрос в WordPress, чтобы он мог сгенерировать ответ. Затем модуль кэширования HTTP будет кэшировать этот ответ на обратном пути.

И Apache, и nginx имеют возможность добавлять систему кэширования HTTP. Модуль nginx встроен. Модуль Apache — это отдельный модуль, который необходимо добавить в установку Apache.

Не так много информации о том, как использовать модуль Apache с PHP или WordPress. Это может быть потому, что он не популярен среди толпы Apache, или, может быть, потому, что у него есть некоторые проблемы. Есть по крайней мере одна давняя проблема, которая все еще остается открытой.

Между тем, система HTTP-кэширования nginx надежна и хорошо документирована. Вы можете использовать его как обычный кэш HTTP или как меньший, но эффективный микрокэш. Это еще одна причина, по которой nginx в настоящее время является предпочтительным веб-сервером.

Добавить лак в стек

Что такое лак? Это выделенный HTTP-кэш-сервер (или, как его любят называть разработчики, HTTP-акселератор). Большинство веб-сайтов с высоким трафиком и хостинговые компании премиум-класса используют его в качестве своего решения для кэширования HTTP.

Они используют его, потому что он мощный и предлагает наибольшую гибкость. Varnish имеет собственный язык конфигурации, который называется VCL. Это позволяет вам контролировать каждый элемент процесса кэширования. Varnish также поставляется с множеством инструментов для анализа того, что делает кэш и как он работает.

Это основные различия между его использованием и использованием только встроенного кэша HTTP веб-сервера. Встроенный HTTP-кеш веб-сервера очень эффективен, но также довольно прост. У вас нет большого контроля, кроме нескольких параметров конфигурации.

Тем не менее, эта мощность и гибкость имеют свою цену. Varnish также является самым сложным вариантом кэширования HTTP. Он ничего не делает, кроме кэширования HTTP-ответов. Он не обрабатывает завершение SSL, чего хотят (или должны хотеть) большинство разработчиков WordPress. Это означает, что наш современный серверный стек WordPress будет более сложным, когда мы будем его использовать.

Диаграмма выше иллюстрирует эту дополнительную сложность. Теперь у нас есть еще два компонента в стеке сервера WordPress: Varnish и обратный прокси.

Обратный прокси-сервер предназначен для преодоления ограничения, которое Varnish имеет с SSL. Он сидит перед Varnish и расшифровывает запросы, которые получает наш сервер. Вы также можете назвать этот тип обратного прокси прокси-сервером завершения SSL. Затем прокси-сервер отправляет эти расшифрованные запросы в Varnish для обработки.

Как только запрос поступает в Varnish, запускаются файлы конфигурации VCL. Это мозг Varnish. Например, они рассказывают ему, как:

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

Последнее особенно важно. Предоставленный сам себе, Varnish не может узнать, когда WordPress хочет удалить страницу из кеша. Таким образом, по умолчанию, если вы вносите изменения в публикацию и обновляете ее, посетители будут продолжать видеть ту же кешированную страницу. К счастью для нас, существует плагин, который удаляет страницы из кеша Varnish.

Вордпресс

Хорошо, наш запрос на домашнюю страницу modern.wordpress-stack.org попал в WordPress. Он прошел через цикл запрос-ответ, который мы только что рассмотрели. Кэш HTTP сделал все возможное, чтобы найти ответ HTTP для отправки обратно.

Но не было кэшированного HTTP-ответа для отправки обратно в браузер. В этот момент у кэша HTTP не было другого выбора. Он должен был перенаправить HTTP-запрос в WordPress.

Теперь все в руках WordPress. WordPress должен превратить наш HTTP-запрос в HTTP-ответ и отправить его обратно в HTTP-кеш. Как мы видели ранее, это главное узкое место всего нашего современного серверного стека WordPress.

Причина этого узкого места двояка. WordPress имеет много кода PHP для выполнения. Это отнимает много времени, и чем медленнее PHP делает это, тем больше времени это занимает.

Другим узким местом являются запросы к базе данных, которые должен выполнять WordPress. Запросы к базе данных являются дорогостоящими операциями. Чем их больше, тем медленнее работает WordPress. Это будет в центре внимания последнего раздела, посвященного циклу запрос-результат.

Оптимизация среды выполнения PHP

Вернемся к PHP. На данный момент WordPress имеет минимальное требование PHP 5.2. Этой версии PHP почти 10 лет! (Команда PHP прекратила поддержку в 2011 году.)

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

Используйте последнюю версию PHP

Самое простое, что вы можете сделать, это обновить версию PHP. В версиях 5.4, 5.5 и 5.6 улучшена производительность. Наибольшее улучшение произошло с 5,3 до 5,4. Переход на него увеличил производительность WordPress на приличную величину.

Установить кэширование кода операции

Кэширование кода операции — еще один способ ускорить работу PHP. Как язык сценариев на стороне сервера, PHP имеет большой недостаток: ему необходимо компилировать сценарий PHP каждый раз, когда он его выполняет.

Решение этой проблемы заключается в кэшировании скомпилированного PHP-кода. Таким образом, PHP не нужно компилировать его каждый раз, когда он его выполняет. Это работа кеша кода операции.

До PHP 5.5 PHP не поставлялся в комплекте с кешем кода операции. Вы должны были установить его самостоятельно на сервер. Это еще одна причина, по которой лучше использовать более новую версию PHP.

Переключитесь на компилятор нового поколения

Последнее, что вы можете сделать, это переключиться на один из двух компиляторов следующего поколения: либо на Facebook HHVM, либо на PHP 7, последнюю версию PHP. (Почему именно PHP 7? Это долгая история.)

Facebook и команда PHP создали эти два компилятора с нуля. Они хотели использовать более современные стратегии компиляции. HHVM использует своевременную компиляцию, тогда как PHP 7 использует предварительную компиляцию. Оба предлагают невероятные улучшения производительности по сравнению со старым добрым PHP 5.

HHVM был первым, кто появился на сцене несколько лет назад. Многие хосты высшего уровня добились большого успеха с ним, предлагая его в качестве основного компилятора PHP.

Однако стоит подчеркнуть, что HHVM не является официальным компилятором PHP. Он не на 100% совместим с PHP. Причина в том, что HHVM предназначен не только для поддержки PHP; это также компилятор языка программирования Facebook Hack.

PHP 7 является официальным компилятором PHP. Его давно нет. Команда PHP выпустила его в декабре 2015 года. Это не помешало некоторым хостинговым компаниям WordPress уже поддерживать его.

Хорошей новостью является то, что сам WordPress на 100% совместим с обоими компиляторами! Плохая новость заключается в том, что не все плагины и темы, потому что минимальная версия PHP для WordPress по-прежнему 5.2.

Ничто не заставляет авторов заставлять свои плагины или темы работать с этими компиляторами. Таким образом, вы не можете пойти ва-банк с одним из них. Ваш стек всегда должен возвращаться к PHP 5.

Цикл запрос-результат

На этом этапе среда выполнения PHP просматривает все PHP-файлы WordPress и выполняет их. Однако эти PHP-файлы WordPress не содержат никаких данных. Они содержат только код WordPress.

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

Это может происходить от нескольких десятков до нескольких сотен раз. (Возможно, вы захотите поговорить со своим разработчиком, если это последнее!) Вот почему это серьезное узкое место.

Оптимизация цикла «запрос-результат»

Целью оптимизации здесь является ускорение времени выполнения файлов WordPress с помощью PHP. Вот где запросы к базе данных проблематичны. Они, как правило, занимают больше времени, чем просто запуск простого PHP-кода (если только ваш код не делает что-то возмутительное).

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

Возможно, мы не сможем уменьшить количество запросов, которые делает WordPress, но у нас тоже есть варианты. Есть еще два способа, которыми стек может помочь нам оптимизировать цикл запроса-результата. В первую очередь это может уменьшить количество запросов к базе данных. А для тех запросов, которые попадают в базу данных, это может сократить время, необходимое для их выполнения.

Обе эти опции предназначены для того, чтобы сделать одно и то же: заставить PHP как можно меньше ждать результатов из базы данных, что сделает сам WordPress быстрее.

Элементы стека для цикла «запрос-результат»

Давайте посмотрим на различные элементы стека, участвующие в цикле запроса-результата. Эта часть стека менее сложна. Но он по-прежнему включает более одного компонента, а именно сервер базы данных MySQL и кэш объектов.

Сервер базы данных MySQL

Несколько лет назад сервер баз данных MySQL значил для всех одно и то же. Это был сервер с установленным сервером MySQL. Но за последние годы многое изменилось.

Различные группы были недовольны тем, как Oracle управляет проектом MySQL. Таким образом, каждая группа разветвила его и создала свою собственную версию, которую вы могли вместо этого «закинуть». В результате теперь существует несколько серверов баз данных MySQL.

Новый «официальный» сервер MySQL — это сервер MariaDB. Это разработанная сообществом версия сервера MySQL. Сообщество планирует поддерживать полную совместимость с проектом сервера MySQL.

Другой популярной альтернативой MySQL является сервер Percona. В отличие от MariaDB, Percona — это скорее ответвление MySQL. Его разработчики не против самого проекта MySQL; они просто хотят сосредоточиться на повышении производительности MySQL. Позже команда MariaDB объединила некоторые из этих улучшений производительности с проектом MariaDB.

В конце дня вы можете выбрать тот, который вы предпочитаете. Нет никакой разницы в производительности между сервером Percona и сервером MariaDB (по крайней мере, для большинства из нас). Они оба работают лучше, чем MySQL. Однако Percona поддерживает более тесную совместимость с проектом Oracle.

Что действительно влияет на производительность, так это механизм хранения, который использует база данных WordPress. Механизм хранения контролирует, как сервер базы данных управляет данными, которые он хранит. Вы также можете установить другой механизм хранения для каждой таблицы базы данных; вам не нужно использовать один и тот же для всей базы данных.

Сервер базы данных имеет несколько механизмов хранения. Мы не будем рассматривать их все. Нас интересуют только два: InnoDB и MyISAM.

По умолчанию WordPress использует стандартный движок базы данных MySQL. До MySQL 5.5 этим движком был MyISAM. Если вы запускаете небольшой веб-сайт WordPress, то MyISAM подойдет. MyISAM сталкивается с проблемами производительности, когда веб-сайт увеличивается в размерах. На данный момент InnoDB является единственным выбором для ядра базы данных.

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

MySQLTuner — это небольшой скрипт, который анализирует ваш сервер базы данных. Он создаст отчет и даст вам рекомендации по настройке.

Кэш объектов

Основная часть работы по оптимизации цикла запроса-результата лежит на кэше объектов. Работа кэша объектов заключается в хранении данных, получение или создание которых занимает много времени. Как вы могли догадаться, запросы к базе данных — идеальный кандидат.

WordPress часто использует кеш объектов. Допустим, вы используете get_option для получения опции из базы данных. WordPress будет запрашивать эту опцию у базы данных только один раз. Он не будет запрашивать его снова в следующий раз, когда он кому-то понадобится.

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

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

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

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

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

Постоянный кэш объектов часто поставляется в виде плагина. Этот плагин будет использовать раскрывающийся object-cache.php для выполнения своей работы. Этот раскрывающийся модуль позволяет авторам плагинов изменять поведение кэша объектов по умолчанию.

Затем подключаемые модули подключают кэш объектов к постоянному хранилищу данных. Они делают это, заменяя функции извлечения и сохранения кэша объектов по умолчанию. Вместо того, чтобы сохранять и извлекать данные в память, кеш объектов делает это из этого хранилища.

Плагины постоянного кэширования объектов

В настоящее время существует два популярных варианта хранения данных для постоянного кэширования объектов:

• Memcached (плагин)
• Редис (плагин)

Оба этих хранилища данных используют оперативную память для хранения, что делает их молниеносными. На самом деле их производительность сравнима с кэшем объектов по умолчанию.

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

Какой из них вы должны установить? На практике нет большой разницы между ними для кэширования объектов. В прошлом популярным вариантом был Memcached. Это изменилось за последние несколько лет. Redis добавил множество функций, которые сделали его популярным вариантом для кэширования объектов.

Получение собственного современного сервера WordPress

Итак, как вы получаете свой собственный сервер? Очевидный способ — получить один из лучших хостинговых компаний WordPress. Эти компании хотят оставаться в авангарде хостингового бизнеса WordPress, что побуждает их внедрять последние достижения и технологии.

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

DebOps для WordPress

DebOps для WordPress — это инструмент, который я создал, чтобы помочь любому создать современный сервер WordPress. Его миссия — сделать современный серверный стек WordPress доступным для всех в сообществе. Вот почему я пытаюсь сделать его максимально простым в использовании. Вам не нужны какие-либо знания системного администрирования, чтобы использовать его.

DebOps для WordPress настраивает сервер следующим образом:

• HHVM (пока PHP 7 не станет официальным репозиторием Linux)
• МарияДБ
• нгинкс
• Редис
• Лак

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

EasyEngine

EasyEngine — это инструмент командной строки, разработанный, чтобы помочь вам настроить веб-сайт WordPress на сервере. Отличительной особенностью EasyEngine является его гибкость: вы можете использовать его для настройки практически любой комбинации серверных технологий, которые мы рассматривали до сих пор.

Например, он позволяет вам настроить сервер с HHVM или PHP 7. Он позволяет вам выбирать между Memcached и Redis для вашего постоянного хранилища данных. И это позволяет вам устанавливать инструменты администратора, такие как phpMyAdmin.

Он также предлагает большое количество опций при создании веб-сайта WordPress. Вы можете указать ему настроить веб-сайт с HTTP-кэшем с помощью плагина или nginx. Именно благодаря этой гибкости EasyEngine так популярен.

решетка

Trellis — это инструмент, разработанный Roots. Как и DebOps, он настраивает сервер с определенным набором серверных технологий:

• МарияДБ
• Memcached
• нгинкс
• HTTP-кэш nginx (необязательно)
• PHP 7

Одна вещь, которую нужно знать о Trellis, — это его связь с Bedrock, еще одним инструментом, созданным Roots. Bedrock — это шаблон для структурирования веб-сайта WordPress на основе принципов «двенадцатифакторного приложения».

Команда Roots создала Trellis, чтобы люди могли настраивать сервер, который использует веб-сайты WordPress со структурой Bedrock. Вы не можете использовать его с обычной установкой WordPress, так что имейте это в виду.

Времена изменились

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

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