Task #8 [Oleynik]

[mikeoleynik]

Проект 1

В этот case study хотел бы включить кейсы из разных проектов, в которых приходилось принимать участие. Один из таких проектов интересен тем, что большАя часть проекта просто зашифрована. Это было сделано предыдущими разработчиками для защиты интеллектуальной собственности (вместо NDA). Приходилось смотреть в логи и по ним понимать, что примерно происходит внутри.

На этом проекте не было мониторинга и при этом были большие проблемы с оптимизацией.

Самой большой точкой роста был N+1 запрос для построения меню. Меню рисовалось на всех страницах приложения, так что это была самая жирная точка роста и от нее надо было избавляться в первую очередь. До кода я добраться не мог. Пришлось закэшировать участок кода во вьюхе.

- cache product_category do
  %li
    = link_to "/catalogs/#{product_category.to_param}.html" do
      ...

Меню меняется редко, поэтому закешировать его - не проблема.
Был момент, когда пришлось захардкодить это меню и вставить чистый html. Это было приемлимо, но решение продержалось недолго. Но как вариант можно использовать.

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

Еще, что заметно прибавило скорости, так это выставление index'ов на все внешние ключи. Искал отсутствующие индексы с помощью гема (не помню название).

На проекте я работал один и честно говоря не было времени всерьез заниматься профилированием.

Проект 2

Проект достаточно давно разрабатывается. С перфомансом на проекте все хорошо. На этом проекте есть мониторинги: Grafana для железа, PgHero для SQL. На вскидку предполагаю, что на проекте есть много N+1, которые мне еще предстоит оптимизировать. В тестах - каскады в фабриках.

1. На этом проекте большой точкой роста является класс, который собирает объекты и потом одним запросом создает сущности в базе. Этот класс был написан еще в 2015 году, но в какой-то момент он исчерпал себя (база растет и теперь при импорте миллиона сущностей память раздувает до ~3gb).

Прирост памяти: 2840.6299mb

Это было до 6 рельсов, сейчас переходим на изкоробочное решение upsert_all/insert_all.

	#upsert_all	custom class
10.000 записей	19.00 MB	75.84 MB
100.000 записей	187.62 MB	756.48 MB
500.000 записей	931.44 MB	:( - все наглухо зависло

В качестве профилировщика использовался memory_profiler. Объемы потребляемой памяти в сравнении с кастомным классом сократились в 4x. Эта оптимизация еще не доведена до прода.

2. Так же на проекте есть кейс (по сути фильтр), который сочетает в себе и ransack и ActiveRecord и чистый SQL. Это достаточно хрупкое место и после добавления нового фильтра кейс начал отрабатывать за минуту.

Первым делом обратился к PgHero, он не показал что запрос является точкой роста. Но в логах я заметил лишние запросы типа Exist? (запрос в логах был не во всех фильтрах). Я начал искать, где в запросе есть проверки на существование записей и нашел #any?. Добавил #load и проблема исчезла. Понимаю что это скорее костыль и проблему надо решать по другому (скоре переписать кейс на query-object стиль и оставить что-то одно).

3. Это небольшая точка роста на любом проекте, это просто хорошая практика :)
   Перечитывая доки, наткнулся на такой кейс. В итоге написал кастомный коп для этого.

4. Прогнал тесты вместе со встроенным профилировщиком rspec spec --profile. Он показал несколько самых медленных тестов, в которых была одна общая проблема: создавался объект вне всех context, а использовался лишь в одном или нескольких. После переноса let в нужный context прирост скорости был очень значительный (в некоторых случаях в два раза с 50 до 23 сек).

[spajic]

Круто, спасибо за интересные кейсы!
Вы конечно вихрем пронеслись через этот курс 🌪️
Надеюсь, что было полезно!

[spajic]

)) своеобразный случай!

[spajic]

👍