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

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

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

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

Ниже приведен обзор иерархии кэширования WordPress с указанием проходимых сегментов:

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

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

О Ядро WordPress. Объекты кэширования, применяемые WordPress, фактически объединяются в кэш поиска по базе данных аналогично способу, применяемому сайтами с высокой масштабируемостью на основе MySQL, например такими, как Facebook. Изменение динамической генерации страницы на статический способ обработки (HTML) позволяет ускорить доступ к странице, однако ино­гда отмечается противоречивость при обновлении данных. Кроме того, как уже упоминалось в главе 11, для ускорения доступа можно кэшировать внешние и сложные информационные объекты, используя временные объекты.

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

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

Сложность оптимизации и ускорения WordPress

Во-первых, система WordPress достаточно сложна, и в этом ее преимущество. WordPress позволяет упростить процесс управления содержимым и за счет си­стемы плагинов расширяет основные возможности, связанные с этим процессом. Однако предлагаемые дополнительные возможности и гибкость системы обе­спечиваются за счет доступа к базе данных, обработки данных РНР, обработки уникальных требований каждого из плагинов и предпосылок каждой из специальных тем. Каждый плагин сопровождается непроизводительными затратами при отображении страниц, а качество кода конкретного плагина зависит от его автора. Используя анализатор выполняемых ветвей, например WebGrind или KCacheGrind, позволяющий вашему приложению выявлять возможные крити­ческие элементы кода, можно обеспечить графическое отображение сложности веб-приложения. Рассмотрим, к примеру, самый простой вариант установки WordPress с темой, предлагаемой по умолчанию. Запустив обычную загрузку страницы через этот профайлер и просматривая график, отображающий процесс выполнения этого запроса, вы увидите, что для отображения запрашиваемой страницы используется более 860 функций (рис. 13. 4).

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

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

Не стоит паниковать по этому поводу и отключать плагины или останавливать свой выбор на самых простых темах. WordPress — уникальная система, и она мо­жет справиться с поставленными задачами. Гибкость, предлагаемая WordPress, а именно возможность изменения настроек во время работы, является мощной, но затратной особенностью. Альтернативой является статистически ограничен­ный набор функций и необходимость вставки новых фрагментов кода для применения новых функций, тогда как WordPress предлагает гибкую архитектуру плагинов. Каждый из предлагаемых плагинов и дополнительных параметров увеличивает функциональность вашей системы WordPress, поэтому вы и пользуетесь ими.

Просто признайте необходимость компромисса между функциональностью и эф­фективностью, где-то незначительного, где-то — более заметного.

На практике ваш сайт не так уж часто меняется. Вряд ли вы пытаетесь запустить на основе WordPress новую социальную сеть вроде Twitter (впрочем, используя тему, вы можете создать ее довольно точную копию), и отображаемое содержи­мое не изменяется каждые 30 секунд. В идеальной ситуации, когда содержимое на вашем сайте просматривается существенно чаще, чем он обновляется, что допускает возможность некоторой несогласованности при обновлении данных, вы сможете отслеживать слои кэширования от веб-сервера до MySQL.

Кэширование и оптимизация работы веб-сервера

Улучшение масштабируемости системы WordPress на уровне веб-сервера требует оптимизации выполнения РНР, а также изменения настроек веб-сервера. В обоих случаях вам потребуются полномочия администратора для доступа к файлам настройки веб-сервера.

Вам предстоит отслеживать запросы MySQL и кэширование объектов, однако независимо от конечного списка страниц WordPress за счет РНР обеспечивается отображение страницы и создание ее HTML -компонента. РНР представляет собой интерпретируемый язык, понятный компьютеру. Код каждый раз интерпретирует­ся и компилируется в машинный код. У этого метода есть плюсы и минусы, но их обсуждение категорически не вписывается в формат этой книги.

Однако исполнительный уровень РНР может кэшироваться при помощи кэша кода операции.

Кэш кода операции РНР пытается замкнуть разрыв между интерпретированием работы системы и полностью компилированным кодом. АРС (или альтернативный кэш РНР) представляет собой один из способов реализации, обеспечивающий кэширование и оптимизацию промежуточного кода РНР. Этот метод никак не от­носится к WordPress и применяется на подуровне РНР вашего сервера, и потому эта конфигурация не рассматривается в этой книге.

Для настройки АРС вам необходимо разрешение на доступ к своему серверу. По­сле настройки АРС выполняется кэширование компилированных файлов РНР, находящихся в памяти WordPress. Основным недостатком является необходимость постоянной перезагрузки сервера при изменении страницы РНР. При изменении тем требуется перезапуск сервера каждый раз, когда в файл шаблона вносятся изменения. Более подробная информация об АРС приведена на сайте

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

Как уже упоминалось в, WordPress выполняет кэширование последних результатов, полученных в запросах SQL, созданных на основе базы данных MySQL, однако если ваш сайт последовательно загружает и затем сбрасывает содержимое кэша по мере того, как пользователи переходят от одного из популярных разделов сайта к другому, этот дополнительный уровень кэширования позволит повысить эффективность, так как будет сохранять в памяти результаты нескольких последних запросов. Кэш объектов WordPress сопоставляется с объектами, управляемыми кэш-памятью, что позволяет удовлет­ворять повторяющиеся запросы за счет содержимого кэша, а не за счет отправки в базу данных очередного запроса SQL. Такой уровень обеспечивает кэширование на уровне кода РНР, сокращая время выполнения РНР благодаря информации, помещенной в кэш ранее. Как будет показано далее, в потоке вычислений преду­смотрены разнообразные возможности для применения кэширования.

При рассмотрении возможностей уровня РНР в контексте WordPress также сле­дует оптимизировать (и обезопасить) конфигурацию вашего сервера php. ini. РНР пользуется таким успехом благодаря множеству встроенных возможностей, которые при этом снижают уровень защищенности системы и облегчают разработчикам их задачу. Это всегда было и главным недостатком, и главным преимуществом РНР.

Откройте файл php. ini и отключите неиспользуемые расширения. Если они по­надобятся в будущем, вы всегда сможете снова включить их.

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

Наконец, на уровне системного администрирования вы можете оптимизировать работу своего веб-сервера. В большинстве случаев конфигурация веб-сервера, пред­лагаемая по умолчанию, предназначена для обработки наиболее общих случаев ис­пользования. Разумеется, потребуется предпринять определенные действия, чтобы обеспечить соответствие определенным запросам. Так, например, сервер Apache идет в комплекте с множеством дополнительных модулей, которые позволяют работать с общими ситуациями. Если вам не нужны эти модули, отключите их. Это позволит сократить объем памяти, необходимый для работы Apache.

На практике можно добиться повышения эффективности работы Apache в условиях ограниченных ресурсов (например, при работе с частными виртуальными серверами с малым объемом памяти) за счет изменения конфигурации Apache PreFork. Конфигурация по умолчанию требует достаточно большого объема памяти, но вы можете ограничить требования к объему памяти в зависимости от нагрузки на ваш сайт и конфигурации вашей системы. Например, в случае размещения сайта с низким уровнем посещения на общем сервере с малым объемом памяти можно изменить файл конфигурации Apache 2 следующим образом (при условии, что вы используете Apache 2):

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

Разумеется, эти настройки следует скорректировать в зависимости от ваших требований.

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

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

Кэширование объектов WordPress

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

Кэширование объектов обеспечивает сохранение ряда часто используемых и цен­ных блоков данных в памяти. Эта процедура схожа с процедурой переходного кэширования, которая была описана в главе 11, однако переходные значения вы как разработчик задаете самостоятельно, тогда как процедура кэширования объ­ектов определяется ядром WordPress. Гибкость процедуры кэширования объектов позволяет исключить влияние изменения части информации на все содержимое кэша, так как изменяются только сохраненные в кэше объекты, претерпевающие изменения. Однако кэширование объектов по-прежнему требует от плагина вы­полнить PHP -код, чтобы определить, какие из фрагментов кэша все еще актуальны; от WordPress также требуется выполнить PHP -код для сведения частей страницы вместе и ее последующего отображения. Как уже упоминалось ранее, оптимизация PHP -среды вашего веб-сервера и включение кэширования объектов на уровне WordPress, как результат, являются псевдонезависимыми.

Иногда предлагаемое вами содержимое достаточно статично или обращение к нему происходит гак часто, ч то необходимо замкнуть блок кода РНР и кэш объекта, например, в случае, когда ваша страница отображается в топе новост­ных сайтов Reddit и Slashdot. Например, это можно сделать, преобразовав соот­ветствующую страницу в статический HTML, и обрабатывать ее напрямую веб­сервером. В конце концов, это именно то, для чего изначально разрабатывался веб-сервер.

Мы считаем, что наиболее подходящим для этой цели плагином является WP – Super Cache, разработанный Доннча Окайом. WP – Super Cache создан на основе плагина WP – Cache и является его улучшением. (Как вы можете заметить, это СУ­ПЕРплагин.) WP – Super Cache функционирует в различных режимах, в том числе в режиме перезаписи статических файлов HTML. Однако для работы со статичными файлами HTML -плагину требуется mod rewrite, и поэтому этот плагин работает только с серверами Apache.

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

Могут применяться и другие плагины для кэширования, например W 3 Total Cache. Многие плагины для кэширования основаны на базовой теме, создающей фраг­менты HTML -кода для страницы и обеспечивающей ее кэширование при помощи URL, используемого в качестве ключа для доступа к этой странице. Каждый плагин предусматривает различные способы определения недействительности содержи­мого кэша и срока действия страниц, и все они нарушают общую динамическую природу генерации страниц в системе WordPress. Если вы собираетесь изменить свою тему, добавить новые плагины или каким-то иным образом изменить поток данных, передаваемых от MySQL к браузеру пользователя, отключите кэширование WordPress и проверьте, работает ли система с внесенными изменениями, либо часто очищайте кэш, чтобы при проверке эффективности с учетом внесенных изменений видеть заново сгенерированные страницы.

Временный кэш

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

Другим способом применения временного кэша является хранение сложных рас­четных данных. Например, в вашем шаблоне functions. php может присутствовать функция, направляющая сложный запрос через вашу сеть WordPress, включающую в себя несколько сайтов, с целью создания средства общесетевой навигации. Эти данные обычно нечасто претерпевают изменения, однако обработка запроса до­статочно важна и может привести к замедлению отображения страницы.

При помощи временного кэша вы можете обрабатывать сложные запросы и со­хранять их во временном кэше, чтобы следующему посетителю не приходилось ожидать выполнения запроса SQL. Использование временного кэша в этом каче­стве повышает работоспособность сайта за счет уменьшения количества запросов, поступающих в базу данных. Выполняя исследовательскую работу при написании этой книги, мы установили систему WordPress в предлагаемой по умолчанию конфигурации, использовав тему «Twenty Eleven». Дополнительные плагины не устанавливались, то есть была уста­новлена исключительно «система из коробки». Для обработки индексной страницы WordPress использует более 20 запросов MySQL. Убедитесь в этом сами, просто добавив приведенные ниже строки кода РНР в файл шаблона footer, php; Перезагрузите страницу, и в ее нижней части отобразится количество запросов и время, затраченное на их обработку. От вас требуется оценить свой сайт, но, по всей вероятности, содержимое, сохра­ненное в базе данных, не может изменяться достаточно быстро, чтобы обеспечить загрузку всех обращений к базе данных по каждой странице. Перевод URL в запрос MySQL рассматривался в главе 5, а в главе 6 рассматривались исходные модели данных, так что объем трафика, необходимого для отображения простой индексной страницы, не должен вас удивить. Кэширование WordPress обеспечивает ускорение доступа к содержимому, получае­мому от MySQL. Если вы хотите дополнительно повысить эффективность MySQL и обеспечить более высокую надежность отклика на запросы от ядра WordPress, потребуется изучить данные о кэше запросов MySQL. Кэш запросов MySQL хранит результаты задачи select (выбрать) на случай поступления идентичного запроса, так как в этом случае из оперативной памяти можно мгновенно извлечь ранее полученные результаты. Это позволит существенно увеличить время отклика на запрос при условии, что данные претерпевают не очень серьезные изменения; в случае более серьезного изменения данных обновленные данные не могут ото­бражаться мгновенно. Для того чтобы включить кэш запросов MySQL, вам потребуется изменить файл конфигурации MySQL -на сервере, однако для того, чтобы это сделать, понадобится разрешение компании — поставщика услуг хостинга. При изменении файла кон­фигурации MySQL вы можете увеличить предел памяти, например: В этом случае важно не устанавливать слишком большие значения. Выделение слишком большого объема оперативной памяти для кэширования запросов MySQL может отрицательно сказаться на других подсистемах вашего сервера. Во всем нужно соблюдать равновесие. Простое включение кэширования таких запросов приводит к возникновению непроизводительных затрат при управлении процес­сами MySQL, но тем не менее вы в итоге оказываетесь в выигрыше. В какой-то момент, как мы надеемся, вы достигнете предела работоспособности пакета программного обеспечения, установленного на физическом сервере. В этом случае потребуется выровнять нагрузку на ваш сайт WordPress, задействовав один или несколько дополнительных серверов. Серверы можно добавить для расширения возможностей сайта в области обработки запросов, или же они могут использовать­ся в качестве ресурса, используемого при сбое, что повысит доступность вашего сайта. Независимо от выбранного варианта выравнивание нагрузки на ваш сайт, по сути, решит обе задачи, однако этот вопрос сам по себе достаточно сложный. Ниже вкратце рассмотрены сложности, с которыми вы можете столкнуться, пытаясь вы­ровнять нагрузку на динамически отображаемый сайт. В первую очередь вам потребуются средства для выравнивания нагрузки. При­менение обычного подхода — использования цикличного DNS для передачи последовательных запросов HTTP между серверами — может повлечь за собой определенные проблемы, особенно в связи с cookie -файлами сеанса. Вам понадо­бится легитимное средство для выравнивания нагрузки, чтобы справиться с этой задачей. В качестве средства для выравнивания нагрузки может использоваться такой пакет программного обеспечения, как Pound.

Все вопросы по ускорению и оптимизации вашего сайта на Вордпресс вы можете задать здесь