Как повысить эффективность моего сервера WordPress GraphQL для статического веб-сайта
Я недавно построенный инструмент создания схемы graphql, который проверяет представление JSON набора расширенных настраиваемых полей WordPress для создания схемы graphql. Представление JSON основано на настраиваемых типах сообщений и расширенных настраиваемых полях, имеющихся в базе данных SQL.
Например, определение настраиваемого типа сообщения с именем Office Location с настраиваемыми полями city и street_address приводит к схеме graphql, которую можно запросить следующим образом:
officeLocations {
post_title
locationInformation {
city
streetAddress
}
}
Это приводит к базовым SQL-запросам формы
SELECT
`meta_id`, `post_id`, `meta_key`, `meta_value`
FROM `wp_postmeta` AS `wp_postmeta`
WHERE `wp_postmeta`.`meta_key` = 'street_address'
AND `wp_postmeta`.`post_id` = 176
LIMIT 1;
а также
SELECT
`id`, `post_author`, `post_title`, `post_content`,
`post_excerpt`, `post_status`, `post_type`, `post_name`,
`post_date`, `post_parent`, `menu_order`, `guid`
FROM `wp_posts` AS `wp_posts`
WHERE (`wp_posts`.`id` = 176 OR `wp_posts`.`post_name` = NULL)
AND `wp_posts`.`post_status` = 'publish'
LIMIT 1;
которые извлекают расширенную информацию о пользовательских публикациях из таблицы wp_postmeta, сначала просматривая таблицу wp_posts.
Использование этого инструмента генерации схемы на целевой странице скромного веб-сайта приводит к 4035 отдельным SQL-запросам к базе данных. Я не уверен, что это необычно, но это приводит к медленному времени выполнения (~ 4 с на моем MacBook Pro 2015 года).
Я хочу повысить эффективность этих запросов graphql для веб-сайта, данные которого редко меняются (по сути, статический веб-сайт). Исходя из исследований, мои четыре основных направления:
- Пакетные запросы с использованием Загрузчик данных Facebook. Я почерпнул из этот источник и изучил возможности пакетирования загрузчика данных для SQL, что может быть сложно пакетировать SQL-запросы, сгенерированные наивными преобразователями graphql.
- Создавайте менее наивные резолверы graphql, используя что-то вроде присоединиться к монстру
- Реализуйте кеширование ключей / значений с помощью Redis или Memcached, которое помещает кеш уровня ответа перед сервером GraphQL
- Скомпилируйте веб-сайт с динамическими запросами graphql в чисто статический веб-сайт, который затем развертывается как статический веб-сайт (удаляя graphql из уравнения)
Меня интересуют относительные достоинства этих проспектов так же, как и любых других.
Полагаю, у меня нет четкого вопроса, однако меня интересуют относительные достоинства различных решений проблемы. Кажется, что загрузчик данных представляет собой «более сложную» проблему для разработки, чем простое кэширование результатов на уровне запроса, однако он не подвергается риску резкого увеличения использования кеша. Я думаю, что для моего конкретного случая использования, поскольку данные по существу статичны, а запросы неизменны, я буду кэшировать на уровне запроса. Я сообщу о своих результатах после внедрения.
Почему бы не использовать плагин wp-graphql? Клиент Apollo может быть лучше в (нормализованном) кешировании запросов, пакетной обработке и т. д.
Ответы 1
Прежде чем приступить к кешированию и другим энергоемким «решениям», давайте сделаем некоторые вещи, чтобы ускорить сами запросы.
Запрос 1 (постмета проблема)
Стандартный wp_postmeta имеет неэффективную схему. Это лучше:
CREATE TABLE wp_postmeta (
post_id BIGINT UNSIGNED NOT NULL,
meta_key VARCHAR(255) NOT NULL,
meta_value LONGTEXT NOT NULL,
PRIMARY KEY(post_id, meta_key),
INDEX(meta_key)
) ENGINE=InnoDB;
См. здесь для объяснения, что делать, если у вас 767 проблем, и как справиться с требованием для meta_id (что в большинстве случаев бесполезно).
Эти советы помогут ускорить большинство запросов, связанных с wp_postmeta.
Запрос 2 (плохая формулировка)
wp_posts.post_name = NULLвсегда выходит из строя; вместо этого скажитеwp_posts.post_name IS NULL.- Без
ORDER BYLIMITдоставит произвольную строку. ORплохо оптимизируется ...
Перепишем так:
SELECT * FROM
( ( SELECT ...
FROM `wp_posts` AS `wp_posts`
WHERE `wp_posts`.`id` = 176
AND `wp_posts`.`post_status` = 'publish'
LIMIT 1 )
UNION DISTINCT
( SELECT ...
FROM `wp_posts` AS `wp_posts`
WHERE `wp_posts`.`post_name` IS NULL
AND `wp_posts`.`post_status` = 'publish'
LIMIT 1 )
) LIMIT 1
И тогда это было бы полезно:
INDEX(post_status, post_id)
INDEX(post_status, post_name)
Если вы добавите ORDER BY, его нужно будет добавить в 3-х местах; непосредственно перед каждым LIMIT.
До: Полное сканирование таблицы wp_posts. В соответствии с моими предложениями: две очень эффективных однорядных выборки плюс определение того, какая из двух строк действительно доставляет.
Кэширование на уровне ответа значительно ускоряет работу, но это не универсальное решение. Я хотел бы разработать что-то на уровне DB или ORM, так что это отличное начало. Я также имею дело с неэффективностью, связанной с обходом двойной таблицы для доступа к категориям WordPress, а также с обработкой ORM для доступа к полям повторителя ACF, как описано здесь.
Я имею в виду, вы упомянули здесь много вещей, и я не знаю, в чем именно заключается вопрос. Использование таких методов, как загрузчик данных, должно иметь логарифмический эффект на количество отправленных запросов. Проблема, с которой вы столкнулись, похоже, связана с тем, что «автоматически генерируемые» и «производительность» - это две вещи, объединение которых требует больших усилий. На самом деле есть несколько компаний, которые пытаются решить эту проблему, например Prisma или Хасура.