From ffb85f11d21c1b27caf31c964b71ee5eabaf1c67 Mon Sep 17 00:00:00 2001 From: Tab Loid Date: Fri, 14 Apr 2023 13:18:22 +0300 Subject: [PATCH] Create case-study.md --- case-study.md | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 case-study.md diff --git a/case-study.md b/case-study.md new file mode 100644 index 0000000..4ed268c --- /dev/null +++ b/case-study.md @@ -0,0 +1,67 @@ +# О моих проектах + +В настоящий момент я отвечаю за большой Rails-монолит (~350k cloc). +Проект является внутренним сервисом производственной компании, активное развитие проекта началось более 10 лет назад. +Сервис покрывает сразу несколько классов задач, но основное направление связано с хранением и версированием конструкторской документации. + +Второй проект с которым я недолко связан - это некоммерческий блог на базе headless CMS ghost (JavaScript). + +## Rails-монолит + +### Плюсы и минусы внутреннего сервиса. + +Основным плюсом внутреннего сервиса явлсяется то что у нас очень ограничен список возможных клиентов. +На нашем предприятии это как правило desktop-версия firefox, у большинства сотрудников широкоформатные мониторы с высоким разрешением. +Наш сервис развернут на внутренних серверах компании с гигабитной сетью, поэтому у нас практически не стоит вопрос об оптимизации на уровне +сети. + +Основным недостатком является то что без внешних клиентов очень сложно объективно рассчитать бюджеты на основные метрики производительности. +Кроме того существенным недостатком является то что даже на крупном предприятии нагрузка на сервис относительно небольшая, +а в нерабочее время нагрузки и вовсе практически нулевая. Данный недостаток проявляется как сложность в оценке производительности из-за +недостатка статистических данных. + +### Состояние сервиса на момент начала курса + +На момент начала курса я уже продолжительное время занимался вопросом производительности, поэтому основа у меня уже была готова, +имелся мониторинг нагрузки на виртуальных машинах, подключен Sentry в качестве APM и сборщика ошибок. Несколько лет назад до +перехода на Sentry для слежения за производительностью мы применяли APM на базе Elastic и Kibana, поэтому уже имели предстваления об основных +проблемных местах. Уже была приобретена книга The Complete Guide to Rails Performance и проведены первые шаги по предложенному чеклисту. +Производительность некоторых действий довольно низкая (таймаут на вормирование ответа выставлен в 5 минут), при этом среднее время полной загрузки +страницы составляет чуть менее 2 секунд (при остуствии альтернатив пользователи могут довольно долго терпеть). +Фронт древний, реализован на базе jquery. + +### Основные сложности оптимизации + +Большинство основных страниц системы представляют что-то вроде дашборда, отображение многих данных зависят от прав доступа пользователей, +поэтому на них достаточно сложно производить кэширование. +В нашем случае мы ещё и ограничены в использовании внешних сервисов, поэтому не можем использовать такие штуки как ScoutAPM или NewRelic. +Одной из основных сложностей связанных с отсутствием доступа к этим сервисов является то, что нет удобного способа для сбора статистики о +потреблении памяти (ни sentry ни elk apm этого пока не умеют). + +### Основное достижение в рамках курса + +Считаю основным плюсом разработку собственного инструмента для произведения последовательных оптимизаций https://github.com/Tab10id/perfolab. +Несмотря на сырость инструмента я даже в таком виде смог дать задачу на оптимизацию одному из младших программистов, который за 3 итерации +смог оптимизировать работу скрипта синхронизации пользователей из ActiveDirectory с 2 часов до 15 минут (помимо самих пользователей в +скрипте осуществлялось обновление прав доступа к внутренним репозиториям). + +Помимо этого хочу добавить несколько слов о системе мониторинга Sentry (хоть о ней и не было сказано в рамках курса). +В последних версиях появился очень хороший механизм отображения основных точек роста, теперь не нужно тратить много времени на исследование, +Sentry сам подстказывает наиболее проблемные sql-запросы, вьюхи которые рендерятся слишком много времени и т.п. + +## Блог на базе headless CMS Ghost + +Я только недавно занялся этим проектом, поэтому не могу написать много подробностей. +Основная проблема сейчас состоит в том что на проекте нет и не предполагается никакого механизма APM, +а мониторинг ограничивается данными о нагрузке на операционную систему на базе хостинга. +Со стороны пользователей имеются жалобы о том, что при написании больших статей ответ системы может происходить только через несколько минут. +Без мониторинга довольно сложно что-то предположить причину, поэтому пришлось полезть в исходники движка. + +Вся система движка настолько модульная, что ядро представляет из себя простое node-приложение предоставляющее REST API. +Админка для написания статей и веб-морда это отдельные приложения которые при необходимости можно чем-то заменить. +Когда полез в код ядра, приятно был удивлён что там уже была реализована базовая пока недокументированная интеграция с +Sentry (но только для сбора ошибок), прикрутить туда трассировку не представляет большой сложности, поэтому я планирую в ближайшее время +оформить соответствующий pull-request. + +Так же как и в случае с предыдущим проектом имеется сложность с рассчётами бюджетов, но уже по причине того, что проект некоммерческий, +приходится ориентироваться только на лучшие практики.