Тормозит трекер ? Есть решение - Views Tracker !

Главные вкладки

Аватар пользователя Crea Crea 4 сентября 2011 в 13:38

Сделал модуль Views Tracker, позволяющий создавать высокопроизводительную замену родному трекеру из ядра. Модуль основан на идеях модуля Tracker 2, но по сути является абсолютно новым, написанным с нуля проектом.
Актуальность модуля можно почувствовать на своей шкуре здесь, на Drupal.ru, где трекер, похоже, кешируется, что убивает основную идею - быстрое отслеживание изменений.

Чтобы получить максимальный прирост производительности от использования модуля, нужно создать view по аналогии с tracker, встроенным в Views, но использовать поля, аргументы, фильтры и критерии сортировки из групп модуля Views Tracker везде, где это возможно:

  • для общего трекера используйте группу Views Tracker
  • для трекера пользователя используйте группу Views Tracker User

Список дополнительных фич и различий между Views Tracker и Tracker2:

  • В отличие от Tracker 2, Views Tracker имеет индекс по типу материала. За счет этого можно создавать разные трекеры для разных групп материалов без потерь скорости.
  • В отличие от модуля Tracker 2, Views Tracker имеет поддержку модуля Node Comments
  • Views Tracker содержит значительно меньше кода, чем Tracker 2.
  • Tracker 2 не поддерживается - значительные изменения происходят за кадром. Видимо, сказывается то, что модуль используется на Drupal.org
  • Tracker 2 имеет интерфейс пользователя, а Views Tracker нужно использовать вместе с модулем Views (или написать свой интерфейс). Поддержка Views в Tracker 2 тоже есть, но почему-то отсутствует в релизе (те самые изменения "за кадром").

Модуль только выложен, возможно имеет баги. Приглашаю желающих к тестированию.

Комментарии

Аватар пользователя Ch Ch 4 сентября 2011 в 13:58

"Crea" wrote:
Чтобы получить все преимущества модуля, нужно создать view по аналогии с tracker, встроенным в Views, но использовать поля, аргументы и фильтры из группы Views Tracker.

Почему бы в модуль не добавить готовый view для этого трекера?

Аватар пользователя Crea Crea 4 сентября 2011 в 14:06

Ch wrote:

Почему бы в модуль не добавить готовый view для этого трекера?

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

Аватар пользователя bsyomov bsyomov 4 сентября 2011 в 15:38

Каждый конечно извращается как хочет, но как некая отправная точка, такой пример был бы весьма полезен.
Банально, например, проще объяснить, измени то-то и то-то относительно примера. Smile

Аватар пользователя Crea Crea 4 сентября 2011 в 16:56

А если пример изменен до нерабочего состояния, то пользователь пойдет жаловаться - создавать issue. Плюс при разработке новых фич придется этот пример обновлять. А это значит больше сил, потраченных на поддержку модуля.
Мне больше нравится точка зрения, что данный модуль - конструктор, и требует понимания работы Views. Клонировать tracker и заменить в нем элементы - не очень сложная операция Smile

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 4 сентября 2011 в 17:11

Если честно, из описания вообще не понял, в чём преимущество вашего модуля перед встроенным во Views вьюсом tracker кроме того, что подключаются хендлеры и плагины из вашего модуля.

Quote:
Чтобы получить все преимущества модуля, нужно создать view по аналогии с tracker, встроенным в Views, но использовать поля, аргументы, фильтры и критерии сортировки из групп модуля Views Tracker везде, где это возможно

Какие «все» преимущества? Хотя бы несколько назовите, пожалуйста.

Аватар пользователя Crea Crea 4 сентября 2011 в 17:23

Слово "высокопроизводительный" вы пропустили ? )) Это единственное преимущество. Если для вас встроенный во Views сойдет - пользуйтесь им на здоровье.
Тут вообще действует естесственный отбор - кому этот модуль нужен, тот об этом знает и понимает предназначение Smile

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 4 сентября 2011 в 17:36

"Crea" wrote:
Слово "высокопроизводительный" вы пропустили ? )) Это единственное преимущество. Если для вас встроенный во Views сойдет - пользуйтесь им на здоровье.
Тут вообще действует естесственный отбор - кому этот модуль нужен, тот об этом знает и понимает предназначение :)

Во-первых, как единственное преимущество может быть «всеми преимуществами»? Wink Во-вторых, вы в заглавном посте сравниваете свой модуль со стандартным трекером, а о том, чем он лучше вьюсовского, не говорите.

Что до производительности... Не знаю, наверное, есть те, кому ваш модуль действительно понадобится, особенно, если вы не будете считать, что те, кому он нужен, сами будут знать о нём и понимать его предназначение Wink А мне действительно он, видимо, не понадобится — у меня на liverbird.ru используется именно вьюсовский (чуть подкорректирован вывод, но сути это не меняет), нареканий по производительности нет.

Аватар пользователя Crea Crea 4 сентября 2011 в 17:55

<a href="mailto:ingumsky@drupal.org">ingumsky@drupal.org</a> wrote:

Во-первых, как единственное преимущество может быть «всеми преимуществами»? Wink

Производительность не черно-белая характеристика. Можно получить прирост маленький, можно большой. Возможно, стоит сменить формулировку.

<a href="mailto:ingumsky@drupal.org">ingumsky@drupal.org</a> wrote:

Во-вторых, вы в заглавном посте сравниваете свой модуль со стандартным трекером, а о том, чем он лучше вьюсовского, не говорите.

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

<a href="mailto:ingumsky@drupal.org">ingumsky@drupal.org</a> wrote:

А мне действительно он, видимо, не понадобится — у меня на liverbird.ru используется именно вьюсовский (чуть подкорректирован вывод, но сути это не меняет), нареканий по производительности нет.

Ну вот видите - о чем я и говорил. Если вас все устраивает то не нужно дергаться Smile

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 4 сентября 2011 в 18:23

"Crea" wrote:
Возможно, стоит сменить формулировку.

Дык! Спасибо за понимание! Wink
"Crea" wrote:
Если вас все устраивает то не нужно дергаться :)

Да я и не дёргаюсь Smile

Аватар пользователя Crea Crea 7 сентября 2011 в 16:27

Приведу пример прироста. Сейчас переношу один сайт с 5 на 6 Дру. С учетом модуля Node Comments там сейчас более 100000 нод. Трекер на вьюс грузится ~ 800 мс даже на моем ноуте с 4ядерным core i7 и SSD: 300 c лишним мс на основной запрос трекера, еще примерно столько же на подсчет количества результатов для пейджера в трекере.
Это только скорость загрузки для пользователя. А уж о нагрузке на сервер при таких цифрах и подумать страшно. Smile Там еще диск насилуется по полной, т.к. временные таблицы создаются на диске, скорее всего...
С использованием этого модуля, каждый запрос из этих 2-х выполняется макс. за 10-20мс. Временные таблицы тоже создаются, но из-за DISTINCT, добавленного системой node access. Их влияние не столь катастрофично (как видно из цифр).

Надеюсь, пример достаточно показателен Smile

Аватар пользователя ingumsky@drupal.org ingumsky@drupal.org 4 сентября 2011 в 20:23

У меня скромнее — около 13 тысяч нод + n комментариев. Понимаю вашу логику, но возникает, как мне кажется, вполне закономерный вопрос — кому нафиг нужен трекер с сотней тысяч результатов в нём? Smile Может просто стоит ограничить вывод первыми десятью тысячами (а то и меньше)? Дёшево и сердито Smile

Аватар пользователя Crea Crea 4 сентября 2011 в 20:50

<a href="mailto:ingumsky@drupal.org">ingumsky@drupal.org</a> wrote:
У меня скромнее — около 13 тысяч нод + n комментариев. Понимаю вашу логику, но возникает, как мне кажется, вполне закономерный вопрос — кому нафиг нужен трекер с сотней тысяч результатов в нём? Smile Может просто стоит ограничить вывод первыми десятью тысячами (а то и меньше)? Дёшево и сердито :)

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

Аватар пользователя Crea Crea 4 сентября 2011 в 20:57

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

Аватар пользователя Valeratal Valeratal 6 сентября 2011 в 15:42

мои 5 центов
1. Модуль под 6-ку. Не хочу показать пионером, но какие ресурноемкие шестерочные сайты еще не купили себе пару-тройку серваков, что им понадобился другой трекер?
2. Чем этот модуль лучше трекера вьюсом, тот что идет в комплекте к вьюс. У меня нод тыщ 40, друпал 7. Трекер вьюсовский вроде работает нормально.

Аватар пользователя Crea Crea 6 сентября 2011 в 16:13

Во-первых, показать страницу за 200мс вместо 800-900 (из моего примера) - уже достататочный повод для замены.
Во-вторых, железо даже самое мощное не резиновое. И как видно из моих цифр, оно работает все равно медленно даже на быстром железе: не знаю как Postgres, а MySQL до сих пор плохо масштабируется на многоядерных процессорах, поэтому по процессору вы упретесь в скорость 1 ядра, какой бы крутой у вас не был сервер, а по дискам упретесь в медленные диски (я сомневаюсь что у вас на сервере SSD - цифры на моем ноуте с SSD достаточно показательные).

Аватар пользователя W32 W32 8 сентября 2011 в 10:27

"Crea" wrote:
В 7 трекер ядреный вроде быстрый сделали. Но вообще, да, не идет )

Жаль, что не идет. Вот если бы еще для 7-ки такое.

Аватар пользователя Valeratal Valeratal 11 октября 2011 в 11:15

а никто не бенчмаркил, ядреный лучше или вьюсовский

Вьюсовский рвет тем, что можно время поставить нормальное (А не "тому назад" и поменять заголовки, и местами колонки.