Вывода похожих материалов в Joomla 2.5
Опции темы
Здравствуйте! Подскажите название Модуля для вывода похожих материалов в Joomla 2.5?
Fktrctq
Fj related articles plus настройка
|
Плагин — супер. Умеет выводить старые, новые и похожие новости. Можно добавлять к ним дату, количество просмотров, описание и картинку. Работоспособность на 2.5 проверена у меня на блоге (в подписи). В конце каждой статьи видно его работу.
| |
Спасибо сказали:
| |
Описание модуля: Этот модуль отображает список ссылок на материалы, которые связаны с тем, что в данный момент отображается в центральной области страницы. Связи определяются по ключевым словам, введённым в параметрах материала.
| |
Спасибо сказали:
| |
|
|
|
По сути что я хочу — на страницу №1 (со статьёй определённой категории «категория 1» ) сделать вывод похожих материалов из разных категорий На страницу №2 (со статьёй из «категория 1» ) сделать вывод похожих материалов из разных категорий На 1 и 2 странице выведенные материалы будут разными Возможно ли такое сделать !? есть ли для этого какие нибудь расширения? Источник FJ Related Articles Blog and List Component
Новая версия программы для Joomla! Версия 3.2 и 3.1! Теперь FJ связанных компонент использует теги, а не ключевые слова простота обслуживания и быстрая обработка. Освободиться от Joomla одиночной категории ограничений. Вы когда-нибудь захотите поместить статью на две или более категорий? Список избранных статей из разных категорий? Создать блог или список, основанный на автора? Этот компонент позволяет создать блог или список макета на основе метки или ключевые слова и автор. Так что вы можете создать любое количество пунктов меню показаны статьи, основанные на любое сочетание метки или ключевые слова. * Создать блог или список макетов в точности как стандартная Категория блога и макеты списка, но с помощью тега или ключевое слово и автор соответствие вместо категории. Вот как это работает. Вы создаете статью с нужными ключевыми словами и информация об авторе. Затем Вам создать блог или список макета и выберите эту статью и пункт меню. Вот и весь сказ! Блог или макет покажет список всех статей, которые соответствуют ключевые слова и сведения об авторе пункта меню статья. Источник Django — Урок 049. Оптимизация производительности Django на примере боевого проектаПоследнее время я посвятил много времени оптимизации сайта и теперь хотелось бы рассказать об этом. Поэтому давайте оптимизируем страницу форума сайта EVILEG . А поможет нам в этом батарейка Django Silk, которая служит для измерения количества запросов к базе данных, а также измерения их длительности. Установка и настройка Django SilkУстанавливаем Django Silk Добавляем его в INSTALLED_APPS а также добавляем MIDDLEWARE Ещё на понадобится добавить urls из django-silk, чтобы можно было просматривать статистику запросов. И последним шагом применяем миграцию django-silk Примечание к Django SilkНе используйте Django Silk на боевом сервере. По крайней мере с такими настройками, как показаны в этой статье. Если у вас есть уже хорошая посещаемость на сайте, например 1400 человек в сутки, то с такими настройками Django Silk просто съест все ваши ресурсы. Поэтому экспериментируйте только на development сервере. Работа с оптимизациейДля начала посмотрим, насколько всё плохо с запросами к базе данных на главной странице форума. Для ясности посмотрим, как выглядит данная страница
Для этого нам нужен всего лишь загрузить интересующую нас страницу и посмотреть статистику запроса в Django Silk.
В данный момент все запросы будут показаны в дебаг режиме. Ситуация получается удручающая, поскольку на загрузку главной страницы форума приходится:
Это очень большие расходы по времени, тем более, что потом все необходимые данные нужно ещё загрузить в объекты, а здесь уже всёбудет зависеть от конкретной реализации класса поля Field. Расход ресурсов получается огромным. Полагаю, что это одна из причин, почему многие считают Django медленным, но на самом деле они просто не разобрались, как настроить и оптимизировать запросы к базе данных. Выполняем оптимизациюПосмотрим, как выглядит изначальный QuerySet для главной страницы форума. Как видите ничего сложного. Именно такие запросы как правило и пишут в самом начале использования Django ORM. А уже потом начинаются вопросы, как оптимизировать производительность Django. Дело в том, что первоначальный queryset, который требуется для отображения данной страницы забирает из базы данных только объекты ForumTopic , но не забирает остальные объекты, которые добавлены в ForeignKey поля модели данных ForumTopic . Поэтому Django вынужден автоматически подгружать все необъодимые объекты тогда, когда они требуются. Но программист знает, что потребуется для каждой отдельной страницы и может указать Django все необъодимые объекты, которые необходимо забрать заранее одним запросов. Давайте сделаем это с помощью select_related. select_relatedДанный метод позволяет забирать в одном запросе ещё и дополнительные объекты из других таблиц. Это позволит объединить множество запросов в один и ускорить выборку, а также уменьшить накладные расходы на подключение к базе данных, посокольку количество подключений уже очень сильно уменьшится. Давайте попробуем выбрать некоторые данные в одном запросе с помощью selected_related . Я знаю, что для моей модели ForumTopic в качестве related можно выбрать следующие поля:
Изначальный запрос к базе данных можно модифицировать следующим образом: После чего посмотрим на результат в Django Silk
Ситуация с количеством запросов уже стала лучше
На следующем рисунке приведена строчка с новым запросом, который имеет 4 join операции.
Как видите, длительность этого запроса составила 19,225 мс . Уже хороший результат. Но я точно знаю, что это не предел. Дело в том, что структура главной страницы форума достаточно сложная, и на ней показано количество сообщений в каждом топике, последнее сообщение, ссылка на ответ решения, а также запрос на профиль пользователя для ответов. И вот здесь приходить очередь prefetch_related метода. prefetch_relatedprefetch_related отличается тем, что позволяет подгрузить не только объекты, которые используются в ForeignKey полях модели, но и те объекты, модели которые имеют поле ForeignKey на модель, кооторая участвует в основном запросе к базе данных. То есть можно подгрузить сообщения в топике отдельным запросом. В данном ситуации я хочу подгрузить следующие поля.
Тогда запрос к базе данных уже выглядит так: А в Django Silk я получаю следующий результат
В итоге имеем следующее:
Это просто отличный результат, которого можно достичь. При этом для пользователя по ощущения страница уже начинает загружаться очень быстро. Но это ещё не всё, заметьте что запрос, которые имет 4 join операции по прежнему находится в районе 17-20 мс. Можем ли мы с этим что-то сделать? Конечно можем, и для этого нам понадобится использование метода only . Метод only позволяет забирать только те столбцы, которые нам нужны для отображения страницы. Но в данном случае нужно будет учесть всё столбцы, которые потребуются, иначе каждый упущенный столбец Django будет забирать отдельным запросом. Поэтому я написал следующий запрос к базе данных И получил следующий результат
Конечно, я привожу лучшие возможные результаты, поскольку всегда имеются некоторые колебания в измерениях, но по данному скриншоту видно, что длительность основного запроса снизилась с 17-19 мс до 11-13 мс . Помимо прочего выборка только нужных полей снижает и потребление памяти, если из базы данных забираются например очень крупные куски текстовых данных, которые при этом не используются в рендеринге страницы. А теперь давайте немного поиграемся с выполнением запросов select_related и prefetch_related Дополнительная оптимизацияДочитав до этого момента, Вы, я думаю, убедились, что использование select_related позволяет очень классно оптимизировать запросы к базе данных. Но есть одно НО . Некоторые проблемы могут возникнуть в использованием класса Paginator , который используется у меня на данной странице. И дело в том, что для Paginatorа необходимо выполнять запрос count, чтобы подсчитать правильное количество страниц. А если запрос будет очень сложным, то и длительность запроса count может оказаться довольно большой и соразмерной с выполнением обычного запроса. Поэтому важным условием может быть написание быстрого и эффектинвого основного запроса, а все остальные объекты лучше будет подгружать с помощью prefetch_related . То есть у вас может быть ситуация, когда лучше выполнить ещё пару дополнительных запросов, чем перегружать join операциями основной запрос. И вот такой запрос к ORM я написал для данной страницы В тоже время я получил следующий результат по производительности
Конечно, Вы можете сказать, что в данном случае здесь не очень-то большой выигрыш. Тем более, что общая скорость загрузки даже немного упала (5 мс), а запросов к базе данных стало на 2 больше, но в тоже время я получил прирорст производительности запросов на 42 процента , а это уже кое-чего стоит. Таким образом, если у вас на сайте имеются очень длительные запросы, которые используются в пагинации и имеют большое количество join операций, то возможно стоит переписать использование select_related на prefetch_related . Это на самом деле может помочь сделать ваш сайт на Django значительно быстрее. Источник ➤detector |
