From eda51155449a7320bbffd5f7144a66a9cc455eec Mon Sep 17 00:00:00 2001 From: SynthesisOne Date: Fri, 11 Jun 2021 02:18:06 +0300 Subject: [PATCH 1/2] added case study --- case-study.md | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 case-study.md diff --git a/case-study.md b/case-study.md new file mode 100644 index 0000000..f00ae76 --- /dev/null +++ b/case-study.md @@ -0,0 +1,70 @@ +## О проекте + +Я работаю в компании Jetrockets. + +Пишем проект для одной американской юридической компании, реализуем единое приложения удовлетворяющее их потребностям, раньше им приходилось использовать различный софт для разных задач, теперь с нашим приложением все находится в одном месте. + +Проект разрабатывается с конца февраля 2020 года. + +Я пришел на проект да и в целом в компанию в конце января 2021, в компании являюсь back-end разработчиком на ruby. + +Приложение представляет собой API которое общается с отдельным фронтом написанном полностью на Svelte. + +Перформанском в проекте особо не занимались поскольку проект предназначен для корпоративного клиента, +Никаких систем мониторинга не используется, разве что шлем ошибки в rollbar + +## Stack +0. Rails 6 +1. Grape для написания API +2. Dry-rb для валидаций и инициализаций +3. PostgreSQL +4. Rspec + +## Case 1 + +Начал оптимизировать проект с самой больной точки, это генерация отчета, его можно было посмотреть в веб версии и экспортировать в разные форматы. + +Проблема состояла в том что это происходило довольно медленно, особенно на моем компьютере, где стоял простой hdd, +порой приходилось лезть на сервер где используется ssd что бы проверить как генерируется отчет. + +Мы это долго задумывали и как появилась возможность перевели работу в sidekiq, не знаю как, но он стал работать в десятки раз быстрее, мне так и не удалось выяснить почему синхронно и асинхронно была такая колоссальная разница во времени, возможно держа соединение открытым на время экспорта, что-то замедляло его. + +## Case 1.1 + +я решил еще больше ускорить экспорт и начал с кода, профилировал его всеми изученными инструментами и особых проблем с кодом не было, он был написан довольно хорошо я нашел парочку больных точек которые не играли особой роли в скорости формирования отчета для экспорта, + +тогда я решил переключиться на базу данных, начал с pgHero, он мне показал медленные запросы, но их причина не была ясна, переключился на NewRelic, благо теперь он бесплатный для одного юзера, собрал небольшую аналитику и заметил что в запросе часто используется поиск по составному полю, я добавил индекс и удалось добиться ускорения примерно на 30% +так же я заметил что часто используется связующая таблица, сделал релоад и магическим образом это помогло добиться двухкратного ускорения экспорта. + +До сих пор остается актуальной проблемой то что мы при экспорте грузим все записи в ОЗУ поскольку при выборке используется сложная сортировка, а батчами такую сортировку не выполнить. + + +## Case 2 + +Занялся тестами, тесты шли 10 минут в одном потоке, а в parallel_tests ~3 минуты. + +Прогнал test-prof на наличие повторяющихся вызовов let и заменил их на let_it_be, за минимальные усилия удалось ускорить экспорт в два раза до 1.4 минуту(+1905 тестов), там еще есть много чего то можно оптимизировать но пока остановился на этом. + +### Итого + +В итоге удалось облегчить жизнь клиентам ускорил им экспорт, так и разработчикам ускорил им тесты. + +К сожалению проект на стадии завершения, сдаем буквально на следующей неделе и многое применить не удастся. + +Но как минимум коллеги оценили ускорение прогона тестов и test-prof точно станет часть проекта. + +### Проблемы при оптимизации + +Поскольку в качестве Api используется Grape то NewRelic не очень хорошо понимал что происходит в ресурсах, и на графиках выполнение Grape могло занимать 80% времени и не понятно что там внутри. + +let_it_be тоже следует применять осторожно поскольку он порождает нестабильные тесты, то проходят, то не проходят, у него видимо какие-то проблемы с ассоциациями которые создаются внутри фабрик. + + + + + + + + + + From bb54b3b90d62cef572dfa5fce09fc503d7b81359 Mon Sep 17 00:00:00 2001 From: IG Date: Thu, 8 Jan 2026 03:35:42 +0400 Subject: [PATCH 2/2] Translate Russian text to English --- Readme.md | 58 ++++++++++++++++++++++---------------------- case-study.md | 66 ++++++++++++++++++++++----------------------------- 2 files changed, 57 insertions(+), 67 deletions(-) diff --git a/Readme.md b/Readme.md index 17abaa1..639795e 100644 --- a/Readme.md +++ b/Readme.md @@ -1,53 +1,53 @@ -# Задание №8 +# Task #8 -В этом задании вам нужно написать `case-study` о том как вы применили знания, полученные на курсе, к своим проектам. +In this task you need to write a `case-study` about how you applied the knowledge gained in the course to your projects. ## To start -Для начала напишите немного о своём проекте. +To begin, write a little about your project. -- что за проект -- как долго уже разрабатывается -- как дела с перформансом -- есть ли мониторинг -- можете ли вы навскидку предположить где в проекте есть что оптимизировать -- какова ваша роль в проекте, как давно работаете, чем занимаетесь +- what kind of project is it +- how long has it been in development +- how is performance going +- is there monitoring +- can you roughly guess where in the project there is something to optimize +- what is your role in the project, how long have you been working, what do you do -Сделайте `PR` в этот репозиторий, и дорабатывайте его по ходу курса. +Make a `PR` to this repository, and refine it as the course progresses. ## Hints -Форма `case-study` - свободная. +The `case-study` format is free-form. -Можно написать в форме интересной технической статьи на Хабр. Потом можно будет и опубликовать. +You can write it in the form of an interesting technical article for Habr. Then you can publish it. -Можно взять за основу форму `case-study` из первого задания. +You can use the `case-study` form from the first task as a basis. ### MVP is OK -Оптимизация не обязана быть доведена до прода. +The optimization doesn't have to be brought to production. -Например, вы рассмотрели какую-нибудь подсистему с `fullstack` точки зрения и придумали как её оптимизировать, сделали `MVP`, получили первые результаты. +For example, you considered some subsystem from a `fullstack` point of view and figured out how to optimize it, made an `MVP`, got first results. -В таком случаем интересно рассказать об этом. +In that case, it's interesting to talk about it. -### О чём интересно рассказать +### What's interesting to talk about -- расскажите об актуальной проблеме; -- расскажите, какой метрикой характеризуется ваша проблема; -- если вы работали в итерационном процессе оптимизации, расскажите как вы построили фидбек-луп; -- если пользовались профайлерами - опишите находки, которые сделали с их помощью; -- расскажите, как защитили достигнутый прогресс от деградации; -- прикиньте, сколько денег сэкономила ваша оптимизация: сократили потребление памяти и сэкономили денег на серверах / ускорили ответ сервера и уменьшили bounce-rate / ускорили прогон тестов и улучшили рабочий feedback-loop для всех участников команды...; если сделали что-то полезное, но сложно понять, как это оценить в деньгах, пишите в `Slack`, обсудим; -- если вы сделали много оптимизаций, расскажите о всех! чем больше - тем лучше! если какие-то из них менее интересны, упомяните о них обзорно; +- tell about the actual problem; +- tell what metric characterizes your problem; +- if you worked in an iterative optimization process, tell how you built the feedback-loop; +- if you used profilers - describe the findings you made with their help; +- tell how you protected the achieved progress from degradation; +- estimate how much money your optimization saved: reduced memory consumption and saved money on servers / sped up server response and reduced bounce-rate / sped up test runs and improved the working feedback-loop for all team members...; if you did something useful but it's hard to understand how to evaluate it in money, write in `Slack`, we'll discuss; +- if you made many optimizations, tell about all of them! the more the better! if some of them are less interesting, mention them in overview; -### Если ничего не приходит в голову +### If nothing comes to mind -Всегда можно оптимизировать тесты вашего проекта с помощью `test-prof`! (если конечно они уже не доведены до идеала) +You can always optimize your project's tests using `test-prof`! (unless of course they're already perfected) -Всегда можно сделать аудит проекта с помощью `sitespeed.io`, `webpagetest`, `pagespeed insights`, `lighthouse` и применить предложенные советы. +You can always audit your project using `sitespeed.io`, `webpagetest`, `pagespeed insights`, `lighthouse` and apply the suggested tips. -## Как сдать задание +## How to submit the task -Сделайте `PR` в этот репозиторий с вашим `case-study`. +Make a `PR` to this repository with your `case-study`. diff --git a/case-study.md b/case-study.md index f00ae76..344328d 100644 --- a/case-study.md +++ b/case-study.md @@ -1,70 +1,60 @@ -## О проекте +## About the project -Я работаю в компании Jetrockets. +I work at Jetrockets company. -Пишем проект для одной американской юридической компании, реализуем единое приложения удовлетворяющее их потребностям, раньше им приходилось использовать различный софт для разных задач, теперь с нашим приложением все находится в одном месте. +We're writing a project for an American law firm, implementing a unified application that meets their needs, previously they had to use various software for different tasks, now with our application everything is in one place. -Проект разрабатывается с конца февраля 2020 года. +The project has been in development since the end of February 2020. -Я пришел на проект да и в целом в компанию в конце января 2021, в компании являюсь back-end разработчиком на ruby. +I joined the project and the company in general at the end of January 2021, in the company I am a back-end developer in ruby. -Приложение представляет собой API которое общается с отдельным фронтом написанном полностью на Svelte. +The application is an API that communicates with a separate frontend written entirely in Svelte. -Перформанском в проекте особо не занимались поскольку проект предназначен для корпоративного клиента, -Никаких систем мониторинга не используется, разве что шлем ошибки в rollbar +Performance in the project wasn't really addressed since the project is intended for a corporate client, +No monitoring systems are used, except for sending errors to rollbar ## Stack 0. Rails 6 -1. Grape для написания API -2. Dry-rb для валидаций и инициализаций +1. Grape for writing API +2. Dry-rb for validations and initializations 3. PostgreSQL 4. Rspec ## Case 1 -Начал оптимизировать проект с самой больной точки, это генерация отчета, его можно было посмотреть в веб версии и экспортировать в разные форматы. +Started optimizing the project from the most painful point, which is report generation, it could be viewed in the web version and exported to different formats. -Проблема состояла в том что это происходило довольно медленно, особенно на моем компьютере, где стоял простой hdd, -порой приходилось лезть на сервер где используется ssd что бы проверить как генерируется отчет. +The problem was that this was happening quite slowly, especially on my computer, which had a regular hdd, +sometimes I had to go to the server where ssd is used to check how the report is generated. -Мы это долго задумывали и как появилась возможность перевели работу в sidekiq, не знаю как, но он стал работать в десятки раз быстрее, мне так и не удалось выяснить почему синхронно и асинхронно была такая колоссальная разница во времени, возможно держа соединение открытым на время экспорта, что-то замедляло его. +We had been planning this for a long time and when the opportunity arose we moved the work to sidekiq, I don't know how, but it started working tens of times faster, I still couldn't figure out why there was such a colossal difference in time between synchronous and asynchronous execution, perhaps keeping the connection open during export was slowing something down. ## Case 1.1 -я решил еще больше ускорить экспорт и начал с кода, профилировал его всеми изученными инструментами и особых проблем с кодом не было, он был написан довольно хорошо я нашел парочку больных точек которые не играли особой роли в скорости формирования отчета для экспорта, +I decided to speed up the export even more and started with the code, profiled it with all the tools studied and there were no special problems with the code, it was written quite well, I found a couple of pain points that didn't play a special role in the speed of forming the report for export, -тогда я решил переключиться на базу данных, начал с pgHero, он мне показал медленные запросы, но их причина не была ясна, переключился на NewRelic, благо теперь он бесплатный для одного юзера, собрал небольшую аналитику и заметил что в запросе часто используется поиск по составному полю, я добавил индекс и удалось добиться ускорения примерно на 30% -так же я заметил что часто используется связующая таблица, сделал релоад и магическим образом это помогло добиться двухкратного ускорения экспорта. +then I decided to switch to the database, started with pgHero, it showed me slow queries, but their cause was not clear, switched to NewRelic, thankfully now it's free for one user, collected a little analytics and noticed that a composite field search is often used in the query, I added an index and managed to achieve about 30% speedup +also I noticed that a junction table is often used, did a reload and magically this helped achieve a twofold speedup of export. -До сих пор остается актуальной проблемой то что мы при экспорте грузим все записи в ОЗУ поскольку при выборке используется сложная сортировка, а батчами такую сортировку не выполнить. +The problem that remains relevant is that during export we load all records into RAM since a complex sort is used in the selection, and such sorting cannot be done in batches. -## Case 2 - -Занялся тестами, тесты шли 10 минут в одном потоке, а в parallel_tests ~3 минуты. - -Прогнал test-prof на наличие повторяющихся вызовов let и заменил их на let_it_be, за минимальные усилия удалось ускорить экспорт в два раза до 1.4 минуту(+1905 тестов), там еще есть много чего то можно оптимизировать но пока остановился на этом. - -### Итого - -В итоге удалось облегчить жизнь клиентам ускорил им экспорт, так и разработчикам ускорил им тесты. - -К сожалению проект на стадии завершения, сдаем буквально на следующей неделе и многое применить не удастся. - -Но как минимум коллеги оценили ускорение прогона тестов и test-prof точно станет часть проекта. - -### Проблемы при оптимизации - -Поскольку в качестве Api используется Grape то NewRelic не очень хорошо понимал что происходит в ресурсах, и на графиках выполнение Grape могло занимать 80% времени и не понятно что там внутри. - -let_it_be тоже следует применять осторожно поскольку он порождает нестабильные тесты, то проходят, то не проходят, у него видимо какие-то проблемы с ассоциациями которые создаются внутри фабрик. - +## Case 2 +Got into tests, tests were running for 10 minutes in a single thread, and in parallel_tests ~3 minutes. +Ran test-prof for repeated let calls and replaced them with let_it_be, with minimal effort managed to speed up the export by two times to 1.4 minutes (+1905 tests), there's still a lot that can be optimized but stopped at this for now. +### Summary +In the end, managed to make life easier for clients by speeding up their export, and for developers by speeding up their tests. +Unfortunately the project is at the completion stage, we're literally delivering it next week and many things won't be possible to apply. +But at least colleagues appreciated the speedup of test runs and test-prof will definitely become part of the project. +### Problems during optimization +Since Grape is used as the Api, NewRelic didn't understand very well what was happening in the resources, and on the graphs Grape execution could take 80% of the time and it's unclear what's inside. +let_it_be should also be applied carefully since it creates unstable tests, sometimes they pass, sometimes they don't, it apparently has some problems with associations that are created inside factories.