Task 8

case-study.md

@@ -0,0 +1,39 @@
+# Задание № 8
+
+### О проекте
+* B2B платформа крупного дистрибьютора косметической продукции, разработанная подрядчиком
+* Первые миграции от 2015 года
+* Проект написан вполне толково, на мой не очень опытный взгляд, с тестами, но признаков перформанса не нашел.
+* Prometheus - Grafana, NewRelic. AppSignal и Rollbar для ошибок
+* Буду по мере возможности, после окончания курса пробовать применять все изученные инструменты. В первую очередь rack-mini-profiler и bullet.
+* Пришел в компанию заниматься разработкой ERP-системы в конце 2017 года, практически одновременно с началом обучения на курсе по Rails в Thinknetica. 
+После отказа компании от подрядчика летом 2019, мне передали проект на поддержку. Исправление ошибок, доставшихся по наследству, доработки функционала, разработка нового функционала.
+
+### Оптимизации
+Еще до начала обучения на курсе, оптимизировал несколько узких мест в проекте методом "пристального взгляда", т.к. о перформансе ничего не знал.
+
+1. Стали поступать жалобы от менеджеров о том, что после завершения заказов клиентами, информация об этом не попадает в ERP-систему.
+
+Разобрался в том как эта информация передается, увидел что в Sidekiq забиты все потоки долго выполняющимися задачами, а нужные воркеры ожидают..
+
+Воркеры, забившие все потоки, создавались колбэками, вызванными при приеме товарных остатков от ERP. Менеджеры выгружают остатки - работа встает.
+В воркере вызывался запрос на изменение параметра у товаров, обернутый в транзакцию, в которой отключались/включались триггеры нескольких таблиц.
+
+Для быстрого снятия остроты ситуации убил задачи в Sidekiq, освободив тем самым очередь.
+Затем сделал проверку необходимости выполнения запроса на изменение параметра у товаров, как оказалось он выполнялся крайне редко, прежде чем выполнять его с отключением триггеров, которые и тормозили.
+
+2. Следующие проблемы: долгая выгрузка клиентов из ERP, которые выгружались со связанными контрактами, долгое сохранение параметров товара в админке и т.д.
+Во всем опять были виноваты триггеры.
+
+Триггреры были в 5 таблицах и выполняли одну функцию - обновление mat.view клиентского прайса.
+
+- Замерил время рендеринга каталога товаров (по логам рельс :facepalm).
+- Сделал миграцию с удалением триггеров и mat.view, созданием view.
+- Замерил время рендеринга каталога товаров после миграции.
+- Время не изменилось, зато недопустимые затраты на поддержание mat.view перестали быть.
+
+3. Пару недель назад поставил `gem pghero`, некоторое время подождал сбора статистики.
+
+- Удалил 22 duplicate indexes, добавил 1 suggested index.
+- Топ в slow queries REFRESH MATERIALIZED VIEW CONCURRENTLY, ALTER TABLE products DISABLE TRIGGER.
+Еще один mat.view, который вроде не напрягал, заменил его на view.