i_want_to_know_everything: Максим свое дело знает) Опять же, как я писал в комментарии к ответу Максим Тимофеев при 50к тормозить не должно и на шареде, если он адекватен. На VPS нормальном и подавно. Прелесть ES в том, что это полный off-load нагрузки и по индексации БД, и по поиску-фильтрации, что очень удобно и полезно, особенно в пиковых режимах. Сам по себе поиск идет по АПИ в другом месте, возвращаемый результат - массив ID товаров, которые выводятся одним простым WP_Query с аргументом post__in.
i_want_to_know_everything: по поводу "работают как-то так" - 100% :) По поводу скорости, увы, боюсь что нормального решения нет. Я не пилил в виде плагина, но рефакторил существующие на весьма крупных екоммерсах и делал с нуля когда проекты целиком мы делали. В конечном итоге все сводилось к тому, что Elastic Search - единственное правильное решение для крупного магазина. Но не для шареда, естественно. Впрочем, более-менее крупный магазин и шаред - вещи изначально несовместимые.
i_want_to_know_everything: Ну кроме граблей в виде промежуточных таблиц и своих кастомных SQL-запросов других вариантов на шареде нету. Выборки по таксономиям быстрые, по метаданным - нет, такова архитектура WP, поиск-фильтрация как таковые в нем не для таких задач. Для таких задач есть сторонние решения, в чем с ними проблема? Я не совсем понимаю, почему не подходит ElasticPress + ElasticSearch Cloud. Или вы свой плагин фильтрации пилите, поэтому пытаетесь сделать лучше аналогов?
в БД WordPress все нужные индексы уже есть, а запросы в целом вполне себе норм. По таксономиям все работает шустро, по мета-данным - вот там как раз индексы не особо предусмотрены и их добавление сильно ситуацию не спасет. Другое дело, что даже на шареде при 50к записей тормозить не должно еще, надо все остальное смотреть. И оbject cache таки да, заметно ускорит. Впрочем, не факт что он есть даже на дорогом шареде, или что выделенной памяти хватит, а то будет постоянная гонка за место в стеке, а не нормальный LRU. Вообще, конечно, делать такие сложные фильтры и с такой БД держаться за шаред - имхо какое-то странное решение. Тут по большому счету любая платформа может подтормаживать. Берется нормальный VPS, ставится специализированный Elastic Search и все, вопрос решен.
Георгий: у меня оно в meta и options было. поэтому легко менялось. Что касается attachment_url то да, тут так просто не избавиться. Смотрите библиотеки/плагины для offload-а на сторонние сервера
sim3x: не люблю его и не использую, у меня все fine-tuned. Да и не в этом дело. Зачем мне грузить слайдер, лайтбокс, скроллимейт и еще десяток скриптов + парочку их css на каждой странице, если нужны они только, допустим, на главной? Или валидация форм нужна только на странице контактов. Примеров масса. То же с большими спрайтами. Во-первых, мы сильно увеличивает общий весь страницы и самый первый приход пользователя - отдаем ему тупо все, а там видно будет - пригодится или нет. И если мы грузим это все на каждой странице - получаем как раз замедление рендера - браузер то на каждой странице будет парсить все скрипты и стили, даже этот десяток не используется. В общем, с точки зрения оптимизации это все надо разделять. И вот тут HTTP/2 в помощь. Это один из примеров. Можно углубляться, но смысла нет. Ответ очень прост - если это корпоративный сайтик небольшой или портфолио - все это не важно. Если это high-load и крупный проект - тогда это мегаважно. Собственно из опыта хайлоада все это и выросло у меня в кастомные решения.
sim3x: конкатенация и спрайты. Генерация этого добра хоть и автоматизирована, но тоже время на поддержку этого всего. В моем случае с WP иногда бывает неудобно, особенности платформы. То же касается загрузки скриптов и стилей только там где надо вместо одного бандла. Картинки тоже, вместо одного большого спрайта - ровно то, что нужно на этой странице. И всем этим добром, предоставленным со стороны фронтенда в разобранном виде, а не одной большой соплей, мне на бекенде управлять гораздо комфортнее и быстрее. Фронтендеру проще - он забилдил автоматом сборку и в ус не дует. А мне потом это надо оптимизировать под максимальную производительность. По мелочи, но в сумме какая-то копеечка на каждом проекте. Меньше обезьяньей работы.
sim3x: Да я в курсе. Там, в принципе, в 105 кажется слайде - единственная точная информация из этого спича. Все остальное - синтетические тесты и подгонка под свой маркетинг. Многое не учтено, много сказано с точки зрения CDN а не реальных приложений, и по packet loss там вопросов к их тестам много... В общем, нюансов вагон и тележка. Фастли еще те жуки. В целом, конечно H2 не является волшебной палочкой, да. Но все же, in real world он прекрасно работает и таки действительно заметно и ощутимо ускоряет. А также снимает часть работы с команды, а экономия ресурса - это профит. Особенно в long term.
Skrolea: Может быть такое, что старый сайт на джумле работал с кешированием, поэтому была нагрузка невысокая. А WP из коробки хоть и готов к кешированию, но сам по себе ничего никуда не кешит, если не попросить. Отсюда все запросы - динамика. И вот тут конечно надо смотреть архитектуру и код, ибо напартачить можно было много где. Агрессивное кеширование может решить симптом (испольование ресурсов), но не решит проблему - все что мимо кеша (например, та же админка), все равно будет жрать ресурсы, и хостер будет слезливо просить перестать насиловать их железо. Впрочем, они это делают при нагрузках 5% уже, им же оверселлить надо, там на одной ноде куча хомячков, а вы за десятерых вдруг кушаете.
Дмитрий S: Да, если руками писать ID постов, то такой вариант норм. Единственное, я бы само поле my_related_posts хранил в виде сериализованного массива (нам сырые данные не нужны), и в 'post__in' не нужно тогда делать implode. К тому же, в будущем, если захотите простенький UI доделать чтобы посты можно было искать и добавлять из админки (страницы редактирования текущего поста), а не ID ручками копипастить, то там массив будет к месту.
Эмм..? Не лучше ли в вашем случае обратиться к специалисту?