Оптимизация JComments - подсчет количества комментариев в блоге - Предложения и пожелания

Кстати Сергей, знаешь что еще плохо но я пока не вижу пути исправить - в режиме блога на странице 20 материалов и соответственно 20 запросов в БД на получение кол-ва комментов, так в принципе в любом интегрируемом компоненте.
Когда кол-во объектов большое, комментариев много, нет индексов - это как то совсем нехорошо получается

в режиме блога на странице 20 материалов и соответственно 20 запросов в БД на получение кол-ва комментов

Чтобы этого не было, надо выдергивать количество комментариев ко всему списку, но заранее, содержимое этого списка (в общем случае) неизвестно. В принципе, можно конечно рассмотреть вариант, когда плагин ставит по тексту страницы метки, где должен показаться счетчик комментариев, коллекционирует идентификаторы комментируемых объектов и потом, в некий момент времени, дергает для всех них одним запросом количества, и, допустим, на JavaScript, обновляет. Но это, как мне кажется, уже несколько извращение.

Самое простое средство снижения нагрузки - кэшировать эти запросы, но тогда цифры будут не совсем честные. Чтобы было все по-честному, надо сбрасывать кэш счетчика конкретного материала если появляются к нему комментарии. Это в принципе можно реализовать, но будет очень приличная нагрузка на кэш... Что тоже, не факт, что хорошо.

Когда кол-во объектов большое, комментариев много, нет индексов - это как то совсем нехорошо получается

индексы по комментариям есть, и по всем полям по которым идет поиск они присутствуют, я смотрел планы запросов, там все нормально.

индексы по комментариям есть, и по всем полям по которым идет поиск они присутствуют, я смотрел планы запросов, там все нормально.

точно, прошу прощения

Я выхожу на избранных сайтах проще - не JComments::getCommentsCount() а в запросе напрямую тягаю  count() с группировкой, для того же com_content тоже в модели прописал

Самое простое средство снижения нагрузки - кэшировать эти запросы, но тогда цифры будут не совсем честные. Чтобы было все по-честному, надо сбрасывать кэш счетчика конкретного материала если появляются к нему комментарии. Это в принципе можно реализовать, но будет очень приличная нагрузка на кэш... Что тоже, не факт, что хорошо.

логично, и первое и второе.
А если заранее в массив класть кол-во комментов для объекта на странице и плагином их выдавать сразу? То есть получаем массив из ObjectID - count и после по ID раздавать. Почти как ты сказал выше, но без JS

Я выхожу на избранных сайтах проще - не JComments::getCommentsCount() а в запросе напрямую тягаю  count() с группировкой, для того же com_content тоже в модели прописал

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

А если заранее в массив класть кол-во комментов для объекта на странице и плагином их выдавать сразу?

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

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

Я тебе более того скажу, я уже подумывал, перехватывать модели category, frontpage и section - технически это возможно, она возвращается по ссылке, следовательно потенциально можно налету в системном плагине "спалить", что сейчас идет работа с com_content, и еще до того, как что-то будет сделано самим компонентом, запросить модель, получить ссылку, и по этой ссылке засунуть свою модель, унаследованную от родительской, но доработанную (перекрываем метод getData, собираем с массива элементов их идентификаторы, делаем запрос, дополняем массив).  Т.е. в принципе, с точки зрения теории, такая "партизанщина" допустима, но могут вылезти косяки с точки зрения совместимости

в принципе я это и имел в виду, только не так подробно

Т.е. в принципе, с точки зрения теории, такая "партизанщина" допустима, но могут вылезти косяки с точки зрения совместимости

совместимость с чем?

совместимость с чем?

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

никто не может дать гарантии, что я один такой умный, и что следующий за моим плагин не заменит модель на свою

если честно я такого пока не встречал. Можно конечно в настройках плагина сделать опционально - заменять модель или нет (для тех кто знает)

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

Уважаемый smart, у Вас не появилось решения проблемы повышенного количества запросов к базе данных?
У меня на главной при подсчете кол-ва комментариев создается 30 запросов (_k2_comments), если есть решение прошу поделиться.
Заранее благодарю!