WP, много переменных - выбрать правильное решение

SeVlad, чуть выше Jovian поинтересовался как это делается.

А по кешированию: я бы в базе хранил и по крону скриптом пересчитывал все комбинации тех самых 3-4 CPF из модели ДВС для всех моделей авто. Там получается около 3000х4 комбинаций - на минуту другую надо сайт останавливать.

Попробовал смоделировать задачу, используя возможности WP Types (parent CPT + children CPT's) и плагин кеширования W3 Total Cache.

Результат противоречивый. Количество запросов к базе в момент создания/обновления кэша равняются 36 штук + 2 штуки за каждый выведенный на странице CPT "модель авто". При 300 штуках этих CPT получается нехило. :)

Количество запросов, используя кешированную копию - 11 штук, не зависимо от кол-ва CPT на странице. Что, собственно, предсказуемо.

Неприятная особенность в связке Types и W3TC - жуткий тупняк в админке ВП, когда на странице "родителя" (CTP "модель двигателя") обновляешь данные нескольких "детишек" (CPT "модель авто"). Может виснуть и на минуту-полторы. Если отключаешь W3TC, то всё работает шустро...

Вопрос: 650 запросов к БД - это очень много? :D Таких страниц на сайте будет всего 2-3... Главное, чтобы не ложился сервер в момент обновления кэша. :)

VPS-ка (KVM) c одним ядром Xeon'a на 3 ГГц, 1ГБ RAM и SSD диском. :)

---------- Добавлено 06.09.2013 в 15:09 ----------

Очень хочется без Крона обойтись...

Т.е. всё-таки нагружают базу.. (я втайне надеялся, что это должно быть в памяти ;) )

Возможно стоит его настроить. Или подобрать другой кеш-инструмент. Не обязательно плагин к ВП. И скорее всего лучше будет НЕ плагин.

Дофига.

А запросов к ним? А генераций? (это же не из кеша).. Вот и будет по неск. тыщ.

Не надо боятся крона. Мб действительно, это лучшее решение.

Только на сколько я понял это страницы с фильтрацией (выбором по параметрам). Насколько реально просчитать все возможные комбинации - вопрос..

В общем, решил я проблему сию. :) Вдруг кому-то будет интересно:

Я создал ещё две таблицы в БД, куда записывается вся нужная инфа.

Обновление "в разные стороны" происходит при каждом сохранении того или иного custom post type -- всё завязано на save_post (и thashed_post для удаления) кастомной функцией. :)

Таким образом я не только синхронизирую нужные мне данные, но и делаю вывод 300-400 постов с краткой инфой (20-30 метаполей) ГОРАЗДО быстрее, потому что внутри таблиц типы данных отлично заточены под нужные, а другого мусора нет. WP же использует всего две таблицы (posts и postmeta) с неоптимальными типами ('Bigtext', 'Bigint' и т.п.), да ещё и всё в каше, и каждая из этих таблиц неимоверно быстро разрастается -- особенно postmeta, если много custom field (как у меня).

Вот как-то так. :) Работает шустро теперь и нагружает сервер только в момент сохранения/обновления post_type. Всё отлично.

Да, я имею дубликаты данных (свои таблицы + таблицы WP), но учитывая их малый объём (100МБ размер БД в худшем случае), я на это забиваю, выигрывая в скорости и гибкости.