Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Надеюсь, моя статья будет полезной.
Ну а выводы то какие?
Что в итоге было сделано?
На сколько это подняло производительность?
Сейчас эта статья больше о полезных для разработчика плагинах, а не о «проблемах производительности».
эту проблему нужно устранить
Не нужно, ну или по крайней мере не сразу. Подобные запросы очень быстро выполняются (главное чтобы индекс по этому полю был), поэтому не факт что после переписывания станет заметно быстрее (=> каждый случай надо индивидуально смотреть).
Кстати, если посмотреть вашу таблицу с кол-во запросов, то получаем что:
317 запросов: 180мс (~0.57 мс/запрос)
17 запросов: 108мс (~6.35 мс/запрос)
13 запросов: 4.5мс (~0.35 мс/запрос)
по-моему, очевидно, что затык не только в количестве.
Кстати, авторы redmine очень любят использовать чрезвычайно медленные в mysql запросы вида
WHERE IN(SELECT) — в первую очень я бы обратил внимание на них (используются, например, при поиске по полям).
Сейчас эта статья больше о полезных для разработчика плагинах, а не о «проблемах производительности».
Да возможно заголовок не совсем корректно отражает суть статьи.
Что в итоге было сделано?
В итоге переписали кучу Active Record запросов. Кое где странички которые открывались по 5-10 секунд, стали открываться за 2. Проблемы с утечкой памяти были тоже в SQL-запросе, который тоже был переписан. Сейчас с производительностью все не плохо.
Кстати, если посмотреть вашу таблицу с кол-во запросов, то получаем что:
Это данные с девелоперской машины. На рабочей разница между двумя SQL-запросами и 300-ми циклическими видна на глаз.
В кучку полезны gem'ов для отладки в особенности SQL запросов добавлю свои 5 копеек:
Bullet — github.com/flyerhzm/bullet как раз поможет найти N+1 запрос
Rails Panel + Meta Request — github.com/dejan/rails_panel удобно покажут это в закладках dev панели Chrome
Bullet — github.com/flyerhzm/bullet как раз поможет найти N+1 запрос
Rails Panel + Meta Request — github.com/dejan/rails_panel удобно покажут это в закладках dev панели Chrome
А сколько у вас задач в Redmine сейчас создано? У нас 1.5кк и есть в некоторых местах серьезные проблемы по производительности. Несколько ускорили работу десятком индексов. Хорошо хоть пользователей всего 200 с копейками, а то сервак валился бы на раз-два-три.
>> В итоге переписали кучу Active Record запросов
А где вы их переписываете? Прямо в основном коде или есть возможность это как-то вынести в плагин? Потом проблем с обновлениями не испытываете?
>> В итоге переписали кучу Active Record запросов
А где вы их переписываете? Прямо в основном коде или есть возможность это как-то вынести в плагин? Потом проблем с обновлениями не испытываете?
А сколько у вас задач в Redmine сейчас создано? У нас 1.5кк и есть в некоторых местах серьезные проблемы по производительности. Несколько ускорили работу десятком индексов. Хорошо хоть пользователей всего 200 с копейками, а то сервак валился бы на раз-два-три.
У нас 21660 задач.
Пользователей около 500 но не все активные.
В коробочном Redmine могут быть большие проблемы если иерархичность задач большую сделать. Там циклических запросов при апдейтах тогда хватает. Но мы принципиально не используем деревья из задач. Они нам не нужны совсем! Только для дерева целей (для управление компанией по целям).
А где вы их переписываете? Прямо в основном коде или есть возможность это как-то вынести в плагин?
Нет основной код мы никогда не трогаем только в плагинах. Речь в статье идет в основном о своих плагинах.
Потом проблем с обновлениями не испытываете?
Это когда как. Если правильно писать, то часто переход с одной версии redmine на другую проходит прозрачно. Но не всегда!
Redmine еще актуален? Читал, что большая часть команды ушла в форк ChiliProject.
ChiliProject похоже мертв (последняя версия около года назад выпущена, репозиторий на гитхабе тоже около года не обновлялся)
Действительно. Англоязычная википедия:
As of 2014, the ChiliProject fork is generally considered to be a zombie project, as only security updates have occurred in the last year. Moreover, the leader of the fork moved on from ChiliProject development in 2012. Finally, the last activity on the ChiliProject Devel list was July 2013, and the most recent commit was August 2013.
На мой взгляд Redmine более чем актуален.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы боролись с проблемами производительности в «Redmine». Кто виноват и как помочь?