Как ускорить страницу категории ZOO? - ZOO

ZOO конкретно тормозила на сервере с кучей других сайтов. Было принято решение, перенести на отдельный сервер. Но не смотря на то, что здесь под один сайт выделено 2 ядра по 2600 и 2 гига памяти тормоза не ушли. Сейчас при открытии страницы категории получаю ошибку (в админке тоже примерно такая же):

1104 - The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT is okay SQL=SELECT c.*, GROUP_CONCAT(DISTINCT i.id) as item_ids FROM #__zoo_category as c USE INDEX (APPLICATIONID_ID_INDEX) LEFT JOIN #__zoo_category_item as ci ON ci.category_id = c.id LEFT JOIN #__zoo_item AS i USE INDEX (MULTI_INDEX2) ON ci.item_id = i.id AND i.access IN (1,5) AND i.state = 1 AND (i.publish_up = '0000-00-00 00:00:00' OR i.publish_up <= '2016-11-07 11:08:57') AND (i.publish_down = '0000-00-00 00:00:00' OR i.publish_down >= '2016-11-07 11:08:57') WHERE c.application_id = 1 AND c.published = 1 GROUP BY c.id

Нагуглил такое решение: _http://gtalex.ru/the-select-would-examine-more-than-max_join_size-rows-primer-optimizacii-sql-zaprosa

Оно про Виртуемарт, но проблема думаю такая же. Попробовал в настройках MySQL сервера повысить MAX_JOIN_SIZE параметр и категория стала открываться, но занимает это минуты по 2. Как я понимаю читаются все 140.000 записей потом выводится категория. При этом счетчика записей у категорий нет, не понятно зачем все пересчитывать, когда можно вывести 50 категорий первого уровня за секунду.

Вопрос к спецам, в каком файле и как можно использовать SET SQL_BIG_SELECTS=1 чтобы категории выводились шустрее?

ZOO конкретно тормозила на сервере с кучей других сайтов. Было принято решение, перенести на отдельный сервер. Но не смотря на то, что здесь под один сайт выделено 2 ядра по 2600 и 2 гига памяти тормоза не ушли. Сейчас при открытии страницы категории получаю ошибку (в админке тоже примерно такая же):

1104 - The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT is okay SQL=SELECT c.*, GROUP_CONCAT(DISTINCT i.id) as item_ids FROM #__zoo_category as c USE INDEX (APPLICATIONID_ID_INDEX) LEFT JOIN #__zoo_category_item as ci ON ci.category_id = c.id LEFT JOIN #__zoo_item AS i USE INDEX (MULTI_INDEX2) ON ci.item_id = i.id AND i.access IN (1,5) AND i.state = 1 AND (i.publish_up = '0000-00-00 00:00:00' OR i.publish_up <= '2016-11-07 11:08:57') AND (i.publish_down = '0000-00-00 00:00:00' OR i.publish_down >= '2016-11-07 11:08:57') WHERE c.application_id = 1 AND c.published = 1 GROUP BY c.id

Нагуглил такое решение: _http://gtalex.ru/the-select-would-examine-more-than-max_join_size-rows-primer-optimizacii-sql-zaprosa

Оно про Виртуемарт, но проблема думаю такая же. Попробовал в настройках MySQL сервера повысить MAX_JOIN_SIZE параметр и категория стала открываться, но занимает это минуты по 2. Как я понимаю читаются все 140.000 записей потом выводится категория. При этом счетчика записей у категорий нет, не понятно зачем все пересчитывать, когда можно вывести 50 категорий первого уровня за секунду.

Вопрос к спецам, в каком файле и как можно использовать SET SQL_BIG_SELECTS=1 чтобы категории выводились шустрее?

Почитайте данную тему: http://joomlaforum.ru/index.php/topic,227130.msg1248212.html#msg1248212

zoo, как и его наследник jbzoo в плане большого кол-ва категорий и итемов весьма печален в вопросах производительности, я все жду jbzoo3, который будет отвязан от zoo и хоть как-то будет приближен к современным скоростям...

В примере 10к записей, у меня 140к. APC, nginx и кеширование в Joomla включены. Но не помогает. Или я не уловил суть Вашего посыла? Хотите сказать, что решение с SET SQL_BIG_SELECTS=1 не сработает для Zoo?

140к? увы, быстрее уже не будет... для понимания почему - поковыряйте таблицы в базе на предмет структуры данных...

зу не предназначено для кол-ва итемов более 25к априори, к сожалению, а такая классная задумка была...

140к? увы, быстрее уже не будет... для понимания почему - поковыряйте таблицы в базе на предмет структуры данных...

зу не предназначено для кол-ва итемов более 25к априори, к сожалению, а такая классная задумка была...

25к, ох... Где же Вы раньше были, когда я выбирал компонент каталога? ) В структурах баз, к сожалению, не разбираюсь.  Может знаете что-то для Joomla, что может осилить такой каталог? В иделае с возможностью миграции с Zoo.

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

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

А если сделать несколько однотипных каталогов в виде разных app и разделить все итемы между ними? В этом случае будет пересчитываться вся база Zoo или только конкретно открываемый каталог?