case-study о проделанной оптимизации

Readme.md

@@ -1,40 +1,33 @@
-# Задание №7. Оптимизация `test-suite` и сбор `DX`-метрик
-
-В этом задании вам нужо попрактиковаться в оптимизации `test-suite` и сборе `DX`-метрик.
-
-## Оптимизация test-suite
-Можно оптимизировать test-suite `dev.to`, либо своего проекта.
-
-В любом случае для сдачи задания нужно написать `case-study` о сделанной оптимизации.
-
-Вооружитесь инструментами, рассмотренными на лекции, и разгоните этот test-suite!
-
-## Сбор DX-метрики
-
-Чтобы запечатлеть свой прогресс и в дальнейшем защитить его от деградации, сделайте сбор `DX`-метрики времени выполнения `test-suite` в `InfluxDB` и постройте график в `Chronograf`.
-
-Сделать это очень просто с помощью https://github.com/influxdata/TICK-docker и https://github.com/palkan/influxer.
-
-Подумайте, как бы вам было удобно прикрепить отправку метрики в `InfluxDB` к прогону тестов.
-
-## Hints
-
-Старайтесь держать `feedback-loop` коротким. `test-suite` `dev.to` целиком в один процесс выполняется около 10 минут, это очень долго.
-
-Используйте семплирование или работайте с конкретными наиболее долгими тестами.
-
-Если вы обнаружите проблему, то выберите какой-нибудь один тест, на котором она воспроизводится, и исправьте её, работая с этим тестом.
-
-Попробуйте все инструменты из `test-prof`!
-
-`json-flamegraph` для всего `test-suite` целиком занимает около `1Gb`. `Speedscope.app` открыть его не может.
-
-C отчётом `stackprof` для всего `test-suite` можно работать через `CLI stackprof`, и через `qcachegrind`.
-
-С `ruby-prof` надо работать ещё аккуратнее, потому что он, как `tracing profiler`, собирает очень много данных, с которыми в дальнейшем тяжело работать.
-
-
-## Чек-лист для сдачи задания
-- [x] PR в этот репозиторий с `case-study` о проделанной оптимизации и достигнутых результатах в описании
-- [x] Если оптимизируете `dev.to`, то сделать `PR` с оптимизацией в https://github.com/hardcode-dev/rails-optimization-2-task4 и добавить в этот PR ссылку на него
-- [x] Добавить скриншот с графиком изменения времени прогона `test-suite` в `Chronograf` по мере оптимизации
+### Case-study оптимизации
+
+Для экспериментов я взял самый медленный спек на своем проекте.
+
+1) Первое что я сделал - прогнал его вместе с `RSpecDissect`:
+```
+[TEST PROF INFO] RSpecDissect report
+Total time: 00:23.176
+Total `let` time: 00:20.298
+Total `before(:each)` time: 00:22.742
+
+Finished in 23.19 seconds (files took 3.52 seconds to load)
+```
+Создание основных сущностей я переделал с помощью `let_it_be` + вынес некоторые операции (создания второстепенных сущностей) в before_all:
+```
+[TEST PROF INFO] RSpecDissect report
+Total time: 00:03.392
+Total `let` time: 00:01.659
+Total `before(:each)` time: 00:03.031
+
+Finished in 4.64 seconds (files took 3.54 seconds to load)
+```
+Время прогона тестов сократилось в 5 раз.
+
+2) Дальше я решил, что надо избавиться от каскадного создания объектов. Для этого подключил `FactoryProf` и прогнал тесты с переменной `FPROF=flamegraph`
+Время прогона тестов сократилось еще в двое:
+Finished in 2.23 seconds (files took 3.57 seconds to load)
+
+3) Так же запускал с `FactoryDoctor`, но замена `create` на `build_stubbed` не дает значительного прироста, возмжно на всех тестах это будет заметнее.
+
+### Резюме
+Выбрав оттельный спек удалось сократить время прогонов тестов в 10 раз.  
+Остальные спеки в целом проходят успешно, но есть и красные с которыми нужно разбираться. Но думаю это не составит труда