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 тоже есть, но почему-то отсутствует в релизе (те самые изменения "за кадром").
Модуль только выложен, возможно имеет баги. Приглашаю желающих к тестированию.
Комментарии
Вот это хороший модуль.
Одобряю.
Есть больной на котором пришлось отказаться от ядрёного и вьюс-вариантов трекера.
Установлю и соберу фидбек
Почему бы в модуль не добавить готовый view для этого трекера?
Может быть, добавлю позднее. Вообще, это не очень важно, потому что я не могу знать, какой именно трекер вам требуется, а с модулем Views каждый извращается, как хочет. Поэтому такой view может быть только примером.
Каждый конечно извращается как хочет, но как некая отправная точка, такой пример был бы весьма полезен.
Банально, например, проще объяснить, измени то-то и то-то относительно примера.
А если пример изменен до нерабочего состояния, то пользователь пойдет жаловаться - создавать issue. Плюс при разработке новых фич придется этот пример обновлять. А это значит больше сил, потраченных на поддержку модуля.
Мне больше нравится точка зрения, что данный модуль - конструктор, и требует понимания работы Views. Клонировать tracker и заменить в нем элементы - не очень сложная операция
Если честно, из описания вообще не понял, в чём преимущество вашего модуля перед встроенным во Views вьюсом tracker кроме того, что подключаются хендлеры и плагины из вашего модуля.
Какие «все» преимущества? Хотя бы несколько назовите, пожалуйста.
Слово "высокопроизводительный" вы пропустили ? )) Это единственное преимущество. Если для вас встроенный во Views сойдет - пользуйтесь им на здоровье.
Тут вообще действует естесственный отбор - кому этот модуль нужен, тот об этом знает и понимает предназначение
Во-первых, как единственное преимущество может быть «всеми преимуществами»?
Что до производительности... Не знаю, наверное, есть те, кому ваш модуль действительно понадобится, особенно, если вы не будете считать, что те, кому он нужен, сами будут знать о нём и понимать его предназначение
А мне действительно он, видимо, не понадобится — у меня на liverbird.ru используется именно вьюсовский (чуть подкорректирован вывод, но сути это не меняет), нареканий по производительности нет.
Производительность не черно-белая характеристика. Можно получить прирост маленький, можно большой. Возможно, стоит сменить формулировку.
Повторюсь, те у кого трекер тормозит, знают, что тормозит и ядреный и вьюсовский. См. выше RxB - это моя целевая аудитория.
Аксель, врубивший здесь кеширование, в принципе, тоже должен уловить идею..
Ну вот видите - о чем я и говорил. Если вас все устраивает то не нужно дергаться
Дык! Спасибо за понимание!
Да я и не дёргаюсь
Приведу пример прироста. Сейчас переношу один сайт с 5 на 6 Дру. С учетом модуля Node Comments там сейчас более 100000 нод. Трекер на вьюс грузится ~ 800 мс даже на моем ноуте с 4ядерным core i7 и SSD: 300 c лишним мс на основной запрос трекера, еще примерно столько же на подсчет количества результатов для пейджера в трекере.
Там еще диск насилуется по полной, т.к. временные таблицы создаются на диске, скорее всего...
Это только скорость загрузки для пользователя. А уж о нагрузке на сервер при таких цифрах и подумать страшно.
С использованием этого модуля, каждый запрос из этих 2-х выполняется макс. за 10-20мс. Временные таблицы тоже создаются, но из-за DISTINCT, добавленного системой node access. Их влияние не столь катастрофично (как видно из цифр).
Надеюсь, пример достаточно показателен
У меня скромнее — около 13 тысяч нод + n комментариев. Понимаю вашу логику, но возникает, как мне кажется, вполне закономерный вопрос — кому нафиг нужен трекер с сотней тысяч результатов в нём?
Может просто стоит ограничить вывод первыми десятью тысячами (а то и меньше)? Дёшево и сердито 
Чтобы вычислить первые десять тысяч, нужно сначала, во-первых, составить полный список результатов согласно критериям выборки, а потом отсортировать его согласно заданному критерию сортировки. Тормоза возникают именно из-за этих двух операций, а не из-за вывода результатов на страницу. С ограничением вывода пейджер справляется замечательно.
Так что это не дешево и сердито, а дорого и бестолково
Нужен
Конечно, если вы не хотите отслеживать ноды по какому-то статическому критерию, можно было бы нужные ноды отфильтровались на раннем этапе. Но практика такова, что критерии всегда динамические - нода, опубликованная 2 года назад, может быть прокоментирована и снова стать актуальной (и это не обязательно тупой некропостинг).
Окей. Наверное, вы правы, а я нет.
Добавил вьюху views_tracker_example, отключенную по умолчанию. В следующем снапшоте появится
мои 5 центов
1. Модуль под 6-ку. Не хочу показать пионером, но какие ресурноемкие шестерочные сайты еще не купили себе пару-тройку серваков, что им понадобился другой трекер?
2. Чем этот модуль лучше трекера вьюсом, тот что идет в комплекте к вьюс. У меня нод тыщ 40, друпал 7. Трекер вьюсовский вроде работает нормально.
Во-первых, показать страницу за 200мс вместо 800-900 (из моего примера) - уже достататочный повод для замены.
Во-вторых, железо даже самое мощное не резиновое. И как видно из моих цифр, оно работает все равно медленно даже на быстром железе: не знаю как Postgres, а MySQL до сих пор плохо масштабируется на многоядерных процессорах, поэтому по процессору вы упретесь в скорость 1 ядра, какой бы крутой у вас не был сервер, а по дискам упретесь в медленные диски (я сомневаюсь что у вас на сервере SSD - цифры на моем ноуте с SSD достаточно показательные).
у меня сервант с SSD, могу сделать бенчмарк
у мну ВПС. Сделать не могу. Так как уже 7-ка. Какие диски - да черт его знает.
Я так понимаю о развитии по D7 речи не идет?
В 7 трекер ядреный вроде быстрый сделали. Но вообще, да, не идет )
Жаль, что не идет. Вот если бы еще для 7-ки такое.
а никто не бенчмаркил, ядреный лучше или вьюсовский
Вьюсовский рвет тем, что можно время поставить нормальное (А не "тому назад" и поменять заголовки, и местами колонки.