Доклад Макса Лапшина рассматривает преимущества использования Erlang для разработчиков на Ruby on Rails, подчеркивая его эффективность в решении задач, связанных с долгоживущими соединениями и обработкой множества запросов одновременно. Erlang предлагает более надежные механизмы работы с ресурсами и параллелизмом, что критично для современных веб-приложений и мобильных сервисов. В сравнении с Ruby и другими языками, Erlang обеспечивает лучшую читаемость кода и устойчивость к ошибкам в многопользовательских системах.

1. ERLANG & RAILS
Зачем рельсовику Erlang
Макс Лапшин. max@erlyvideo.org
2011

2. Этот доклад о том
зачем рельсовику знать Erlang
какие задачи Erlang решает лучше и удобнее чем Rails
почему Erlang, а не Scala/Node.js и прочая фигня

3. Сетевой демон 80-х
Написан на C
Кошмарен в отладке
Чрезвычайно сложный failover и балансировка
Требует дорогих программистов
Работал с концепцией подключенного пользователя

4. Реалии 90-х
Индустрия платного показа картинок
Кастомизация кода под разные бизнесы
Новый класс программ: сайты

5. PHP («запрос-ответ»)
Простой язык программирования
Все проблемы с ресурсами решаются схемой «запрос-
ответ»
Программа живет максимум 2000 мс
Сложности с персистентными соединениями

6. Модель «запрос-ответ»
Никакой сборки мусора
Никакого управления ресурсами
Никакой обработки ошибок
Гарантированная однопоточность
Открытие ресурсов на каждом запросе
Инициализация кода на каждом запросе

7. Rails
Доведенный до совершенства PHP
По одной копии программы на ядро с последовательной
обработкой запросов
Сборка мусора
Но всё равно это «запрос-ответ»
Stateless

8. Проблемы Rails
Нельзя отложить выполнение кода после ответа
Фоновое выполнение кода (delayed job и его ужасы)
Огромное потребление памяти на один запрос
Дорогая обработка длинных запросов и сетевых
подзапросов (http-вызовов)

9. Отсутствие возможности
выполнить код
вне схемы «запрос-ответ»

10. А веб тем временем
меняется

11. Интерактивный веб
Каналы передачи данных по инициативе сервера
Много долгоживущих соединений
Больший объём фоновой работы
Железо тоже на месте не стоит (128 ядер уже в продаже)

12. Мобильные приложения
Коммуникации с iPhone приложениями
Android push (один вызов на каждое устройство)
Много интеграции сетевых сервисов

13. Facebook и клоны
HTTP дорос до того, что бы массово заменить Corba
Части подсистемы общаются по HTTP API
Требуются механизмы контроля за частотой и объёмом
вызовов с клиентской стороны

14. Технические сложности
Схема с одним процессом на соединение не работает
Многотредное программирование — кошмар
Фреймворки на коллбеках — кошмар
Возникает проблема обработки ошибок и контроля
ресурсов

15. Erlang
Не академическая поделка типа Scala и не сырая поделка
хипстеров от программирования
Разрабатывается и обкатывается в телеком оборудовании
Дизайнился не за выходные, как JS, а несколько лет
Ericsson и Бобук пытались отказаться от него — не
получилось

16. Erlang пригоден для:
Comet/Websockets
Агрегация сетевых вызовов (facebook/vk)
Интеграции с не-HTTP
Memory state

17. Comet
Долгоживущие HTTP-запросы: сервер посылает ответ в
момент генерации данных
Каждый запрос авторизуется по логике приложения и
регистрируется на получение сообщений определенного
типа
Проблема в роутинге сообщений, который специфичен для
конкретного сайта
1 000 000 открытых сессий — не предел

18. Агрегация запросов
Пока Rails делает HTTP-запрос, всё стоит и ждет
На Erlang можно сделать 10 000 параллельных HTTP-
запросов и даже не заметить этого
Facebook приложения, Android push
Легко делаются параллельные вызовы с таймаутами

19. Интеграция с не-HTTP
Конечно же Jabber!
SMTP/POP3
LDAP
И прочие statefull сетевые протоколы, данные из которых
нужны на HTML-страничке

20. Memory state
Игры
Чаты
Прочая realtime коммуникация пользователей

21. Memory state
Задача — сберечь базу данных и уменьшить задержку
Убрать ненужные чтения и записи в БД
Отдавать ответы из локального кеша в памяти, а не из базы
Обрабатывать данные в локальном кеше

22. Memory state
Очень проблемно, если писать на Ruby/Java и т.п.
Утекание памяти
Утекание ресурсов (открытые файлы)
Обработка ошибок становится важнейшей задачей
Моментально пропадает ощущение bulletproof

23. Memory state & Erlang
Вместо тредов процессы (сотни тысяч)
Между ними нет общей памяти
Коммуникация процессов и таймауты через сообщения
Эффективное использование многоядерности
Очень эффективный сетевой стек
Немутабельные значения

24. Memory state & Erlang
Язык высокого уровня (не C, примерно в 10 раз короче
Java)
Вместо лапши из асинхронных (сетевых)
вызовов — обычные вызовы функций
Эффективные средства тестирования (fuzzy testing)
Полный контроль за состоянием системы включая
консоль внутри сервера

25. Memory state & Erlang
Ошибка в обслуживании одного клиента не обваливает
весь сервер
Не требуется писать код для обработки ошибок
Все и ресурсы освобождаются с закрытием процесса

26. Erlang лучше чем:
Java потому что при той же скорости гораздо читаемей
Ruby потому что эффективно использует ресурсы
Node.js потому что построен не на коллбеках
Всех вместе своей обработкой ошибок и простотой

27. Memory state & Erlang
Каждый пользователь — отдельный процесс
Коммуникация пользователей — посылка сообщений
Общие данные в процессах-агрегаторах
Обновление кода без отключения пользователей

28. Результаты
Wooga: с 5 млрд SQL запросов до 5 млн
Уменьшение парка серверов в несколько раз
Уменьшение времени ответа

29. Резюме
Веб меняется в сторону большей интерактивности
Надо работать с мобильными приложеними и соц-сетями
У Rails есть технические проблемы, связанные с дизайном
Erlang их решает