Медленная работа Tickets

Здравствуйте.
На сайте используется Tickets.
Сайт, что-то типа блога. Имеется одна категория в которую пишутся все тикеты.
Количество тикетов уже 311000.
Основной запрос на выборку 10 тикетов в категории (разделе) очень медленно выполняется. Более 60 секунд.
Кто-нибудь использовал Tickets в таких же условиях? Такая же скорость?
Андрей
22 мая 2013, 08:09
modx.pro
1
2 193
0

Комментарии: 19

Василий Наумкин
22 мая 2013, 13:10
0
311 000 тикетов? Фигасе.

Это скорее всего связано с тем, что там криво написана выборка по parents c depth — по карте ресурсов всегда получаются id потомков и включаются в запрос. А карта у тебя ооочень большая.

В MS2 уже поправил, попробуй изменить getTickets так:
else {
	// Filter by parents
	if (empty($parents) && $parents != '0') {$parents = $modx->resource->id;}
	if (!empty($parents) && $parents > 0){
		$pids = array_map('trim', explode(',', $parents));
		$parents = $pids;
		if (!empty($depth) && $depth > 0) {
			foreach ($pids as $v) {
				if (!is_numeric($v)) {continue;}
				$parents = array_merge($parents, $modx->getChildIds($v, $depth));
			}
		}
		if (!empty($parents)) {
			$where['parent:IN'] = $parents;
		}
	}
}

Ну а после этого вызывай getTickets с параметром &depth=0. Должно помочь.
    Мордынский Николай
    22 мая 2013, 13:35
    0
    а когда выйдет обнова в репозитории? ms2 с этой заплаткой
      Василий Наумкин
      22 мая 2013, 13:36
      0
      Как запущу бета-тест нашего репозитория — новая версия MS2 будет там.

      Надеюсь на завтра.
    Андрей
    22 мая 2013, 14:02
    0
    Василий, внес твои изменения — все по прежнему.
    Начал копать дальше. Выполнил запрос из mysql-редактора.
    Всплыло вот что. Проблема в самом mysql — долго выполняется сброс данных и их сортировка.

    EXPLAIN запроса


    Профайлер запроса


    Есть у кого-нибудь какие либо мысли?
      Василий Наумкин
      22 мая 2013, 16:45
      0
      Мысль тут только одна: расставить дополнительных индексов (например, на deleted индекса нет) и написать свой собственный сниппет для вывода тикетов.

      Убрать там все ненужные плюшки, лишние джоины и, возможно, разбить на несколько запросов, например отдельно считать кол-во комментов у тикета, или не считать вовсе.

      Честно говоря, я вообще удивлен и очень рад, что 300 тысяч тикетов в принципе работают.
        Андрей
        22 мая 2013, 17:04
        0
        Скорее всего так и буду делать.
        Евгений Борисов
        22 мая 2013, 17:04
        0
        Покажи весь запрос
          Андрей
          22 мая 2013, 17:15
          0
          SELECT SQL_CALC_FOUND_ROWS 
          `Ticket`.`id`, `Ticket`.`type`, `Ticket`.`contentType`, `Ticket`.`pagetitle`, `Ticket`.`longtitle`, `Ticket`.`description`, `Ticket`.`alias`, `Ticket`.`link_attributes`, `Ticket`.`published`, `Ticket`.`pub_date`, `Ticket`.`unpub_date`, `Ticket`.`parent`, `Ticket`.`isfolder`, `Ticket`.`introtext`, `Ticket`.`richtext`, `Ticket`.`template`, `Ticket`.`menuindex`, `Ticket`.`searchable`, `Ticket`.`cacheable`, `Ticket`.`createdby`, `Ticket`.`createdon`, `Ticket`.`editedby`, `Ticket`.`editedon`, `Ticket`.`deleted`, `Ticket`.`deletedon`, `Ticket`.`deletedby`, `Ticket`.`publishedon`, `Ticket`.`publishedby`, `Ticket`.`menutitle`, `Ticket`.`donthit`, `Ticket`.`privateweb`, `Ticket`.`privatemgr`, `Ticket`.`content_dispo`, `Ticket`.`hidemenu`, `Ticket`.`class_key`, `Ticket`.`context_key`, `Ticket`.`content_type`, `Ticket`.`uri`, `Ticket`.`uri_override`, `Ticket`.`hide_children_in_tree`, `Ticket`.`show_in_tree`, `Ticket`.`properties`,
          `Section`.`id` AS `section.id`, `Section`.`type` AS `section.type`, `Section`.`contentType` AS `section.contentType`, `Section`.`pagetitle` AS `section.pagetitle`, `Section`.`longtitle` AS `section.longtitle`, `Section`.`description` AS `section.description`, `Section`.`alias` AS `section.alias`, `Section`.`link_attributes` AS `section.link_attributes`, `Section`.`published` AS `section.published`, `Section`.`pub_date` AS `section.pub_date`, `Section`.`unpub_date` AS `section.unpub_date`, `Section`.`parent` AS `section.parent`, `Section`.`isfolder` AS `section.isfolder`, `Section`.`introtext` AS `section.introtext`, `Section`.`richtext` AS `section.richtext`, `Section`.`template` AS `section.template`, `Section`.`menuindex` AS `section.menuindex`, `Section`.`searchable` AS `section.searchable`, `Section`.`cacheable` AS `section.cacheable`, `Section`.`createdby` AS `section.createdby`, `Section`.`createdon` AS `section.createdon`, `Section`.`editedby` AS `section.editedby`, `Section`.`editedon` AS `section.editedon`, `Section`.`deleted` AS `section.deleted`, `Section`.`deletedon` AS `section.deletedon`, `Section`.`deletedby` AS `section.deletedby`, `Section`.`publishedon` AS `section.publishedon`, `Section`.`publishedby` AS `section.publishedby`, `Section`.`menutitle` AS `section.menutitle`, `Section`.`donthit` AS `section.donthit`, `Section`.`privateweb` AS `section.privateweb`, `Section`.`privatemgr` AS `section.privatemgr`, `Section`.`content_dispo` AS `section.content_dispo`, `Section`.`hidemenu` AS `section.hidemenu`, `Section`.`class_key` AS `section.class_key`, `Section`.`context_key` AS `section.context_key`, `Section`.`content_type` AS `section.content_type`, `Section`.`uri` AS `section.uri`, `Section`.`uri_override` AS `section.uri_override`, `Section`.`hide_children_in_tree` AS `section.hide_children_in_tree`, `Section`.`show_in_tree` AS `section.show_in_tree`, `Section`.`properties` AS `section.properties`, 
          `User`.`username`, 
          `Profile`.`internalKey`, `Profile`.`fullname`, `Profile`.`email`, `Profile`.`phone`, `Profile`.`mobilephone`, `Profile`.`blocked`, `Profile`.`blockeduntil`, `Profile`.`blockedafter`, `Profile`.`logincount`, `Profile`.`lastlogin`, `Profile`.`thislogin`, `Profile`.`failedlogincount`, `Profile`.`sessionid`, `Profile`.`dob`, `Profile`.`gender`, `Profile`.`address`, `Profile`.`country`, `Profile`.`city`, `Profile`.`state`, `Profile`.`zip`, `Profile`.`fax`, `Profile`.`photo`, `Profile`.`comment`, `Profile`.`website`, `Profile`.`extended`, 
          SUM(`Vote`.`value`) AS `votes`, 
          COUNT(DISTINCT `View`.`uid`) as `views`, 
          `LastView`.`timestamp` as `new_comments`, 
          COUNT(DISTINCT `Comment`.`id`) as `comments` 
          FROM `modx_site_content` AS `Ticket` 
          LEFT JOIN `modx_tickets_views` `View` ON Ticket.id=View.parent 
          LEFT JOIN `modx_tickets_views` `LastView` ON Ticket.id=LastView.parent AND LastView.uid = 1 
          LEFT JOIN `modx_tickets_votes` `Vote` ON Ticket.id=Vote.parent AND Vote.class='Ticket' 
          LEFT JOIN `modx_tickets_threads` `Thread` ON Thread.resource=Ticket.id  AND Thread.closed=0 AND Thread.deleted=0 
          LEFT JOIN `modx_tickets_comments` `Comment` ON Comment.thread=Thread.id AND Comment.published=1 
          LEFT JOIN `modx_site_content` `Section` ON Section.id=Ticket.parent 
          LEFT JOIN `modx_users` `User` ON User.id=Ticket.createdby 
          LEFT JOIN `modx_user_attributes` `Profile` ON Profile.internalKey=User.id 
          WHERE  ( `Ticket`.`class_key` = 'Ticket' AND `Ticket`.`published` = 1 AND `Ticket`.`deleted` = 0 )  
          GROUP BY `Ticket`.`id` 
          ORDER BY createdon DESC 
          LIMIT 10
            Евгений Борисов
            22 мая 2013, 18:06
            0
            1) modx_tickets_threads индекс к deleted
            2) modx_tickets_votes индекс к class
            3) modx_tickets_comments индекс к published, createdby
            4) modx_site_content индекс к deleted

            Без внедрения в код больше ничего не сделать. В идеале конечно разбить запрос на части. Я думаю у василия это уже в планах, т.к. разговор у нас с ним на эту тему был;-)
            А вообще, после простановки этих индексов должен чутка быстрее работать не только листинг тикетов. Кстати, если не сложно покажите SHOW PROFILE и EXPLAIN запроса после простановки индексов.
              Василий Наумкин
              22 мая 2013, 19:07
              0
              modx_tickets_votes — вообще пока не используется, это задел на систему голосования за тикеты и комменты.

              Базовый сниппет я пока не планирую менять, ибо тут всё-таки крайне необычная ситуация. И я так понимаю, на 100 000 не особо тормозило =)

              Если на сайте такая гора документов, значит с посещалкой все окей, и можно написать свой собственный сниппет для выборки из БД.
                Слава
                30 августа 2019, 14:39
                0
                Василий подскажите пожалуйста:
                Планируем на тикетах сделать сервис отзывов.
                По скромным оценкам будет 1,5 миллионов отзывов.

                Вопрос:
                1. Потянет ли Tickets такие объёмы?
                2. Есть возможность проводить поиск по самим комментариям в тикете?

                Спасибо
                  iWatchYouFromAfar
                  01 сентября 2019, 14:36
                  +1
                  Я конечно не Василий, но отвечу вам.

                  1. Что значит потянет Tickets? Тут скорее вопрос, потянет ли MODx. Создаете чистый сайт, пишите скрипт который сгенерит вам 1.5 млн тикетов (отзывов). Смотрите и тестируете результат, скорость, поиск и т.д. За последний месяц, тут уже обсуждали, потянет ли MODx большой объем данных… Поищите.

                  2. mSearch2 индексирует комментарии Тикетс из коробки. С этим проблем нет.
                    Слава
                    15 октября 2019, 09:40
                    0
                    Собственно развернул сайт. В итоге получилось порядка 800 000 комментариев и тикетов более 300 000.
                    Вcе работает более менее нормально на VPS.
                    Но имеется проблема в работе административной части, а именно в выводе вкладки с комментариями: joxi.ru/KAgBwwMcEW3qo2

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

                    Может есть смысл написать Василию чтобы поправили работы именно административной части сайта?
                      Николай
                      15 октября 2019, 11:15
                      0
                      Тикетами можно сказать не пользовался, но логика одна и та же практически во всех компонентах. Таблицы (и другие компоненты Extjs) в админке получают (обновляют) данные в БД делая запрос к процессорам, и уже процессоры выполняют всю работу с БД. Вот папка со всеми процессорами тикетов. Найти тот, который отвечает за вывод комментов (или какое-то другое действие), обычно это getlist.class.php в соответствующей папке. Чтобы не править исходники, можно расширить родной процессор, сделать свою логику получения данных, если что-то не устраивает, и новый файл в той же папке разместить. А путь к процессору подменить на фронте админки, вот так я подменял для таблицы товаров минишопа:

                      Ext.ComponentMgr.onAvailable('minishop2-grid-products', function(){
                          this.config.baseParams.action = "mgr/product/customgetlist";
                          this.config.save_action = 'mgr/product/customupdatefromgrid';
                      });

                      То есть в конфиг таблицы подсунул свой путь к процессору. Похожий js-файл подгрузить к странице каким-нибудь событием. У меня было минишоповское msOnManagerCustomCssJs, в тикетах может быть своё, не знаю. Или родными движка подключить скрипт к админке. Но это всё конечно имеет смысл, если реально данные выбираются не самым лучшим способом. Ну или используются всякие там MODXовские методы, проверка прав и т.д. Они могут снизить скорость. В конце концов в процессоре можно хоть на чистом SQL данные из БД получить. Так что тут вопрос не в движке или ограничениях админки, а в умении выбирать данные из БД, ну и целесообразности применения каждого способа. Где-то прокатит getCollection, а где-то нет.
                    Алексей Смирнов
                    01 сентября 2019, 20:15
                    +1
                    У меня при 100т ресурсов + 2 TV поля в индексе (всего около 8,5 мл строк) поиск с использованием mSearch2 если искать 1 слово распространенное (любовь) находит 30 тыс ресурсов — примерно за 30...40 сек. Если искать менее распространенное слово, например розетка, общее время посика 5 сек… (VPS у меня), но при выводе еще время тратится на сам вывод (там 1 рес + 4 TV).
                    Думаю, если вы хотите максимальной производительности, то на готовых решениях не будет все комфортно. Советую делать свои таблицы и поиск (а лючше посмотреть поиск в сторону специализированных решений, например Sphinx).
                  Андрей
                  23 мая 2013, 11:27
                  0
                  Евгений, добавил предложенные индексы.
                  Запрос отрабатывается чуть быстрее, на 5-10 секунд. Но это не решает проблемы.
                  Однозначно нужно переделывать/разделять запрос.
            Александр Донский
            22 мая 2013, 21:50
            0
            Если не секрет чем обусловлена такое количество? Это короткие какие-то заметки или статьи, или какой-то другой контент?
              Андрей
              23 мая 2013, 11:28
              0
              Что-то типа доски объявлений
              Слава
              30 августа 2019, 14:35
              0
              м
                Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
                19