From 20b652f73f872e115414516b8306f515aa3a86b6 Mon Sep 17 00:00:00 2001 From: avbelyshev Date: Sat, 3 Jul 2021 01:18:30 +0300 Subject: [PATCH] Add case-study.md --- case-study.md | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 case-study.md diff --git a/case-study.md b/case-study.md new file mode 100644 index 0000000..d36804a --- /dev/null +++ b/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.