Homework. Task 8.

case-study.md

@@ -0,0 +1,24 @@
+1. Я работаю в одном из учреждений Минкомсвязи, проект, которым занимаюсь в основном -- система мониторинга цифровизации регионов РФ. Проект существует несколько лет. На некоторых эндпоинтах видны "просадки" перфоманса той или иной степени. По одному из них руководство поставило мне задачу по оптимизации, которую и использую для 8-го ДЗ по данному курсу.
+2.  Наш проект должен предоставлять определённые данные по `API`. В виду большого объёма обрабатываемых данных, обработка `JSON`-ответов на запросы происходит не на лету, а с помощью кэширования. `Resque` раз в 15 минут запускает задачу, из которой происходит обращение к рассматриваемому контроллеру. В экшене этого контроллера происходит проверка наличие файлов с закэшированными данными. Если файла с соответствующим названием нет или данные в нём устарели, происходит генерация нового файла. Если файл есть и он актуален, то происходит отдача этого файла. В итоге клиенты при запросах на этот эндпоинт мгновенно начинают получать подготовленные данные (обновляемые раз в 15 минут). `Resque` воркеры при создании файлов потребляют много ресурсов (как по памяти, так и по `CPU`), задача заключалась в оптимизации именно этой ступени технологической цепочки.
+3. Фидбэк построил с помощью `rake`-задачи, из которой запускал выполнение `resque`-работы на ограниченном (для вменяемого времени обратной связи) объёме данных. В теле этой же задачи замерял время выполнения и потребление памяти до и после выполнения задачи. Попробовал сначала делать это в `development` окружении -- задача выполнялась `650` секунд. Создал `local_production` -- ускорение почти в 4 раза:
+```bash
+# RACK_ENV=local_production RAILS_ENV=local_production bundle exec rails test_generate:run         
+
+Cleaning public/system/budget/ directory...
+Running TestGenerateEventsApiJob task...
+Run time: 174.28 sec.
+Memory increase equals 1923 Mb.
+```
+Соответственно, продолжил работу на `local_production`. Защиту на соответствие данных в генерируемых файлах решил сделать в той же `rake`-задаче -- сравнивал предварительно созданный заведомо верный `JSON` с тем, что получался при выполнении задачи. Делал это не с помощью тестов, т.к. хотел проверять работу на реальных данных, а не сфабрикованных в изначально пустой тестовой базе.
+4. Первым делом завернул задачу в `stackprof`. Ничего бросающегося в глаза не обнаружил -- в топе были гемы, код самого приложения встречался где-то на 15-ом месте и ничего криминального на первый взгляд не нёс.
+5. Запрофилировал задачу в `ruby-prof` -- чуть более многословно. Видно, что много времени (66%) проводится в `Jbuilder`, из которого идут вызовы различных методов `ActiveRecord`. Но по коду самого приложения по-прежнему никаких намёков на неоптимальность.
+6. Сделал вывод, что упор надо делать на профилирование памяти и работу с ней. Воспользовался `memory_profiler`. В топе -- `ActiveRecord` и `Jbuilder` (обращающийся к первому, как показывают предыдущие отчёты). Изучил гугл. Убрал `Jbuilder` -- переписал рендерер по принципу, изложенному в [этой статье](https://medium.com/neuronio/performance-comparison-for-json-generation-in-ruby-cc2cce55cf0b). Также, там, где было можно, перешёл на `Oj`. Итого:
+```bash
+# RACK_ENV=local_production RAILS_ENV=local_production bundle exec rails test_generate:run         
+
+Cleaning public/system/budget/ directory...
+Running TestGenerateEventsApiJob task...
+Run time: 133.63 sec.
+Memory increase equals 844 Mb.
+```
+По памяти `х2.27`, по времени -- `х1.3`.