Онлайн-воркшоп для Ruby и Rails разработчиков, которые сталкиваются с ростом нагрузки в своих проектах и хотят повысить их производительность, масштабируемость и эффективность. Вы получите практические навыки и разберетесь с нюансами создания устойчивых к нагрузкам решений.
Этот воркшоп для вас если:
- Ваше приложение не справляется с нагрузкой и начинает медленно обрабатывать запросы по мере увеличения числа пользователей
- Ваше приложение часто выполняет задачи в фоновом режиме, такие как отправка писем или генерация отчетов
- Вы работаете с большими объемами данных и сталкиваетесь с продолжительным временем обработки
- Вы хотите раз и навсегда разобраться с concurrency и параллелизмом в Ruby и научиться использовать их так, чтобы не выстрелить себе в ногу
Программа воркшопа
День 1. Основы параллельных вычислений в Ruby
Рассмотрим способы выявления неэффективных процессов, теория основ параллельных вычислений в Ruby, использование Thread и Fiber.
Результат: Поймете, как определить проблему производительности и решишь её “в лоб” используя параллельные процессы в Ruby на практике.
Содержание:
- Введение в многопоточность и параллелизм: различия и преимущества.
- Как находить узкие места производительности в Ruby-приложении.
- Использование потоков (Thread) для параллельных вычислений: создание, управление, проблемы синхронизации.
- Работа с легковесными процессами: введение в Fiber и его применение.
- Практические примеры параллельной обработки: простые задачи и многопоточные решения.
- Проблемы конкурентности: race-conditions, deadlock, и как с ними бороться.
- Ограничения GIL (Global Interpreter Lock) в Ruby и как его обойти.
День 2. Параллельные вычисления в Rails
Узнаем, как параллельные вычисления могут быть интегрированы в веб-приложения на Ruby on Rails, и задействуем второй уровень оптимизации: фоновые задачи и очереди в Sidekiq.
Результат: Сможете настроить параллельных вычислений в фоновых задачах Rails, контролируемо улучшить производительность выполняя задачи параллельно.
Содержание:
- Управление зависимостями и очередь задач в параллельных вычислениях. Обеспечение уникальности выполнения задач, продолжение обработки очереди после ошибки.
- Советы по оптимизации фоновых процессов: минимизация задержек и контроль параллельных операций, логгирование, профилирование.
- Метрики производительности для фоновых задач: мониторинг и оптимизация.
- Подходы к обработке ошибок и ретрай задач в многопоточных системах.
- Race condition, deadlock, retry failures.
- Потеря данных при неожиданном завершении.
- Memory bloat, database contention.
День 3. Оптимизация работы с базами данных
Поговорим о том, как параллельные вычисления помогают ускорить работу с большими объемами данных. Рассмотрим подходы к оптимизации SQL-запросов и блокировках, race-condition при параллельной обработке данных.
Результат: Научитесь оптимизировать запросы к базам данных, минимизировать нагрузку и использовать параллельные вычисления для ускорения работы с большими данными без deadlock и потери данных.
Содержание:
- Параллелизм и базы данных: как эффективно распределить нагрузку между процессами и сохранить консистентность данных.
- Оптимизация SQL-запросов для параллельной обработки: индексирование, версионирование.
- Управление транзакциями в параллельных вычислениях: как избежать конфликтов и deadlock.
- Проблемы блокировок (lock) и race-conditions при многопоточности в работе с базами данных.
- Использование ActiveRecord для параллельных вычислений: как улучшить производительность запросов.
- Кейсы работы с большими объемами данных: импорты, миграции, анализ данных в фоновом режиме.
Автор – Денис Савицкий:
- 12 лет в web-разработке, финтехе: оптимизировал обработку данных, оптимизировал процессы, руководил продуктовой разработкой.
- Разобрался с параллельными задачами, когда пришлось оптимизировать 4‑х часовой хрупкий ежедневный импорт обновлений 30 тысяч яхт и опций. Ускорил его до 20 минут.
- Многопоточность применил для создания агрегатных торговых данных для сделок на бирже — 8 млн записей за месяц по одному тикеру, собирал минутные и дневные суммарные данные, ежедневно. Время ожидания 3‑х месячных данных для графика упало с 240с до 500мс.
