Joomla getItems Пагинация по умолчанию

Может ли кто-нибудь сказать мне, автоматически ли функция getItems() в модели добавляет глобально установленный LIMIT перед выполнением запроса (из getListQuery()). Joomla действительно борется, пытаясь кэшировать все результаты (здесь более 1 миллиона записей!).

После просмотра /libraries/legacy/model/list.php И /libraries/legacy/model/legacy.php оказалось, что getItems() действительно добавляет LIMIT к setQuery, используя $this->getState('list.limit') перед он отправляет результаты в кеш, но если это так, почему Joomla так сильно борется.

Итак, что происходит? Почему phpMyAdmin может возвращать ограниченные результаты в течение секунды, а Joomla просто тайм-аут?

Большое спасибо!


model pagination components joomla large-data
person mousebat    schedule 05.07.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Он добавляет нумерацию страниц автоматически.

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

Это может быть настоящим убийцей, у меня запросы выполнялись более одной секунды с выделенным сервером и всего 3000 элементов контента. Обнаруженный нами компонент облака тегов может занять до 45 секунд, чтобы вернуть список ключевых слов. Если это ситуация (много записей и много объединений), ваш единственный выход — еще больше ограничить фильтры в параметрах, чтобы посмотреть, сможете ли вы получить более быстрые результаты (например, ограничение статей за последние 3 месяца может значительно сократить необходимое время).

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

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

person Riccardo Zorn    schedule 06.07.2013

arrow_upward
2
arrow_downward

Если у вас есть миллион записей, вы определенно захотите сделать, как предлагает Риккардо, переопределить и оптимизировать модель.

JModelList запускает запрос дважды, один раз для номеров страниц, а затем для самого запроса отображения. Вы захотите аккуратно наследовать от JModellist чтобы избежать запроса на разбиение на страницы.

Кроме того, запрос статей печально известен своими соединениями. Вы определенно можете потерять часть этого замедления (например, сомневаетесь, что используете ссылку контактов).

Если все статьи видны всем, вы можете убрать проверку ACL - это довольно дорого.

Нет ни одного администратора баз данных с Запада или Востока, который мог бы объяснить, почему все эти GROUP BY.

Потеря этих вещей значительно поможет. На самом деле лучше всего создать запрос с нуля.

person AmyStephen    schedule 07.07.2013
comment
Привет, спасибо - я только что отказался от JPagination, и он загружается намного быстрее! Дело в том, что я хочу сохранить JPagination, но изменить функцию getTotal, чтобы вместо подсчета строк из полного запроса база данных вместо этого выполняла подсчет выбора. Может ли кто-нибудь порекомендовать, как это сделать, не взламывая основной код Joomla? - person mousebat; 08.07.2013