-
Notifications
You must be signed in to change notification settings - Fork 50
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 7 #39
base: master
Are you sure you want to change the base?
Optimise performance 7 #39
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 very nice work!
|
||
После того, как мы создали график отслеживания времени прохождения тестов и получили отправную точку (523 секунды), пора переходить к исследованию тестов с помощью профилировщиков. | ||
|
||
Предварительно мы сразу можем исключить из пакета тестов системные (в папке `spec/features`), т.к. они обрабатываются наиболее медленно, симулируя пользовательский ввод в браузере. Важно заметить, что они игнорируются только при запуске всего пакета тестов (цель - feedback-loop), но будут выполняться, если мы укажем целенаправленно папку с ними как объект тестирования. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
|
||
Предварительно мы сразу можем исключить из пакета тестов системные (в папке `spec/features`), т.к. они обрабатываются наиболее медленно, симулируя пользовательский ввод в браузере. Важно заметить, что они игнорируются только при запуске всего пакета тестов (цель - feedback-loop), но будут выполняться, если мы укажем целенаправленно папку с ними как объект тестирования. | ||
|
||
Следующим подготовительным шагом станет изменение конфигурации для запуска тестов параллельно, что тоже должно сократить время полного прохождения всего пакета тестов. Сама библиотека для решения этой задачи уже была установлена в проекте (и был отдельный исполняемый файл для обращения к ней), но я решил обновить версию на более актуальную и сделать доступной отдельную базу для каждого потока выполнения тестов. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
там не потоки, а процессы
|
||
## Результаты | ||
|
||
В результате проделанной оптимизации удалось существенно ускорить время выполнения основных релевантных тестов (без задействия браузера) в 10 раз: 523 секунды превратились в 58. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 10x
## Результаты | ||
|
||
В результате проделанной оптимизации удалось существенно ускорить время выполнения основных релевантных тестов (без задействия браузера) в 10 раз: 523 секунды превратились в 58. | ||
В качестве работы на будущее следует провести оптимизацию с помощью Factory Doctor (Total (potentially) bad examples: 123, Total wasted time: 00:05.565), например начав с тестов моделей Article, Notification, User, и продолжив на основании процентного соотношения выполнения тестов рефакторинг с помощью `before_all` и `let_it_be`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Очень часто фабрик слишком много создаётся из-за каскадов
Имеет смысл посмотреть с FPROF=1 rspec
case-study
о проделанной оптимизации и достигнутых результатах в описанииPR
с оптимизацией в https://github.com/hardcode-dev/rails-optimization-2-task4 и добавить в этот PR ссылку на него: igor-arkhipov/performance-improvement-7 rails-optimization-task4#137test-suite
вChronograf
по мере оптимизации