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

Optimise performance 8 #40

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions case-study.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
# Case-study оптимизации рабочего проекта

## To start

- что за проект
* программный комплекс, состоящий из высоконагруженной веб-платформы (15-80 млн реквестов в сутки) и мобильных приложений для оказания услуг учебным заведениям, работодателям и студентам, связывающий эти три группы пользователей воедино.
Copy link
Collaborator

Choose a reason for hiding this comment

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

💪

- как долго уже разрабатывается
* проекту около 10 лет (ruby on rails монолит с позже добавившимися минисервисами (rails engines) и теперь преобразуемый по методолгии DDD в packages)
- как дела с перформансом
* неплохо, т.к. ведется мониторинг всех систем и непрерывно внедряются улучшения по снижению времени отклика, оптимизируются запросы к БД, рефакторится старый код
- есть ли мониторинг
* да, основные популярные системы: datadog, bugsnag. происходит трекинг всех пользовательских путей. внедрена система Service Level Objectives, налажена работа с инцидентами (интеграция мониторов в slack + PagerDuty)
- можете ли вы навскидку предположить где в проекте есть что оптимизировать
* безусловно, три точки роста - это оптимизация запросов к БД (борьба с N+1, загрузка связей на раннем этапе, кэширование), облегчение сборки фронтэнда и оптимизация времени выполнения тестов.
- какова ваша роль в проекте, как давно работаете, чем занимаетесь
* фулл-стек разработчик с фокусом на бэкэнде, в этом проекте около 9 месяцев, основная работа на данном отрезке времени была посвящена локализации продукта для выхода на европейский рынок

### О чём интересно рассказать

- расскажите об актуальной проблеме;
* одна из последних оптимизаций была направлена на снижение размера бандла фронтэнд части за счет перекомпоновки загружаемых переводов
- расскажите, какой метрикой характеризуется ваша проблема;
* размер бандла, связанное с этим время скачивания
- если вы работали в итерационном процессе оптимизации, расскажите как вы построили фидбек-луп;
* речь шла больше о технической стороне самой реализации и изменению загрузчика, проверяя функционал с помощью автоматизированных тестов
- если пользовались профайлерами - опишите находки, которые сделали с их помощью;
* панель разработчика в браузере + панели мониторинга после загрузки в тестовое окружение и "выше". не было подключено эффективное сжатие при передаче (настройка CDN), переход на Brotli усилил эффект еще больше.
Copy link
Collaborator

Choose a reason for hiding this comment

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

👍

- расскажите, как защитили достигнутый прогресс от деградации;
* автоматизированные тесты
- прикиньте, сколько денег сэкономила ваша оптимизация
* можно судить по нагрузке на CDN, она снизилась в 2-3 раза по объему отдаваемого трафика. размер бандла был уменьшен на примерно 600кб. при этом стал загружаться только один пакет переводов, а не все языки по умолчанию (такие библиотеки как date-fns этим грешат по умолчанию). бандл был далее оптимизирован и разбит на части, отвечающие ролям пользователям и их активным локалям.
Copy link
Collaborator

Choose a reason for hiding this comment

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

👍 👍

- если вы сделали много оптимизаций, расскажите о всех
* дополнительно другой отдел фронтэнд платформы смог закончить настройку и активацию экспериментальной функции webpack для lazy loading.
* Для архитектуры Apple M1 первый билд снизился со 176 сек до 25; Перекомпиляция снизилась с 10-13 секунд до 1-3. Это наибольший эффект за долгое время в плане улучшения пользовательского опыта для локальной разработки.
* в моих личных планах подключение недостающих профилировщиков в проект для локальной разработки и обновление тех инструментов, которые пересекаются с предложенными в рамках курса. в частности я заметил, что нет удобного инструмента pghero и Rails panel, а rack mini profiler отключен по умолчанию в UI. воспользовавшись pghero, сразу нашлись 54 продублированных индекса в БД. Т.е. единичные индексы, которые уже проиндексированы в рамках скомбинированных с другими полями.
* большой потенциал ускорения тестов, несмотря на использование test-prof применение let_it_be и before_all ограничено. И, конечно, есть большие и неэффективные фабрики. в запасе так же есть гипотеза оптимизации PostgreSQL в плане отключения Write Ahead Log при выполнении тестов.