Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HW 8 #18

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

HW 8 #18

wants to merge 1 commit into from

Conversation

Halvanhelv
Copy link

No description provided.

Copy link
Collaborator

@spajic spajic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

respect 💪


## Stack
0. Rails 6
1. Grape для написания API
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ох, grape кстати тяжкая штука в части мониторинга и оптимизаций.
На каждом проекте приходили к желанию выпилить grape )

Проблема состояла в том что это происходило довольно медленно, особенно на моем компьютере, где стоял простой hdd,
порой приходилось лезть на сервер где используется ssd что бы проверить как генерируется отчет.

Мы это долго задумывали и как появилась возможность перевели работу в sidekiq, не знаю как, но он стал работать в десятки раз быстрее, мне так и не удалось выяснить почему синхронно и асинхронно была такая колоссальная разница во времени, возможно держа соединение открытым на время экспорта, что-то замедляло его.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Хм, да, загадочно

тогда я решил переключиться на базу данных, начал с pgHero, он мне показал медленные запросы, но их причина не была ясна, переключился на NewRelic, благо теперь он бесплатный для одного юзера, собрал небольшую аналитику и заметил что в запросе часто используется поиск по составному полю, я добавил индекс и удалось добиться ускорения примерно на 30%
так же я заметил что часто используется связующая таблица, сделал релоад и магическим образом это помогло добиться двухкратного ускорения экспорта.

До сих пор остается актуальной проблемой то что мы при экспорте грузим все записи в ОЗУ поскольку при выборке используется сложная сортировка, а батчами такую сортировку не выполнить.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Если вам это правда хочется исправить, то можно например в postgres создавать временную табличку на время работы этой джобы, где будет два столбца - FK на исходную табличку и значение показателя сортировки, которое считается в ruby.

Батчами заполнить эту табличку.

А далее приджойнить её к основной и отсортироваться по рейтингу.

Ну что-то в этом духе.


Занялся тестами, тесты шли 10 минут в одном потоке, а в parallel_tests ~3 минуты.

Прогнал test-prof на наличие повторяющихся вызовов let и заменил их на let_it_be, за минимальные усилия удалось ускорить экспорт в два раза до 1.4 минуту(+1905 тестов), там еще есть много чего то можно оптимизировать но пока остановился на этом.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Да, 2x минимальными усилиями это кайф 👍

А если учесть ещё параллелизм, то 6x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants