Рельсы прекрасный инструмент, но в некоторых ситуациях они не справляются. В этом докладе рассказывается о таких ситуациях и одном из вариантов решения

1. Там, где рельсы не
справляются
Макс Лапшин
max@maxidoors.ru

2. Как делали веб в древности?
● Программы на С
● Кошмар и ужас
● Баснословно долго и дорого
● Сплошные велосипеды
● Перл немножко облегчил

3. Мир веб-приложений (PHP)
● малое время жизни программы
● нет контроля за ресурсами
● share nothing
● внешняя персистентность (Mysql)
● запрос-ответ
● очень удобно делать магазинчики!
● сборка мусора? Не слышали о таком

4. Rails
● Всё то же самое, но в совершенстве
● Самое правильное расслоение
● Самый читаемый код
● Web 1.5

5. Веб меняется
● Растут нагрузки
● Запрос-ответ,ответ,ответ
● Просто ответ, ответ, ответ

6. Масштабируемся железом?
20 мс CPU на обработку запроса
8 ядер
400 RPS — максимум

7. Масштабируемся железом?
Если запросы дергают сеть, то при 100 МБ
на воркер и 32 ГБ, лимит по памяти — 300-
500 одновременных соединений

8. C10K?
Не слышали

9. C100K, C1M?
Можно забыть

10. Масштабируемся железом?
Расти с 10 до 100 серверов ок
Расти со 100 до 1000 серверов — не ок

11. Что лимитирует
производительность?
● Память
● CPU
● Ненужные обращения к ресурсам

12. Что с запросами и ответами?
● Сервер теперь сам шлет данные клиенту
● Подключенные клиенты (!)
● Состояние в памяти (!)
● Все достижения PHP рушатся как
карточный домик

13. Как бы так обслуживать клиентов
из одной копии программы?

14. Варианты
● Eventmachine
● Twisted
● Node.js

15. Проблемы
● Управление ресурсами
● Обработка ошибок
● Управление ресурсами
● Контроль нагрузки
● Управление ресурсами
● Управление ресурсами

16. Ресурсы
● Память
● Внешние соединения
● Память
● Локальное железо (диски и т.п.)
● Память

17. Внезапно вы можете перегрузить
собственный сервер!

18. Ошибки
● Как обрабатывать?
● Как отпускать ресурсы?
● Как освобождать память?

19. Утечка ресурсов — бич
долгоживущей программы

20. Контроль нагрузки
● Глубокая тема
● Надо уметь говорить нет: HTTP 503
● Иногда лучше подольше, да понадежнее
● Back pressure

21. Erlang
● четкий
● резкий

22. Erlang
● multicore
● изоляция данных, клиентов и проблем
● удобный само-мониторинг
● концепция процессов

23. Где может пригодиться?
● онлайн игры
● pub/sub, кометы и прочие мессенеджеры
● брокеры рекламы, ссылок и т.п.
● долгоживущие серверные задачи
● прочие in-memory API сервисы

24. Ruby/Python
● Привычно
● Нет multicore
● Кооперативный
шедулинг
● Единая память
● stop-world GC
● плохая
интроспекция
Erlang
● Отлежавшаяся
технология
● true multicore
● вытесняющий
шедулинг
● нет пауз в GC
● hot code reload
● изоляция
ресурсов и ошибок
● интроспекция

25. Erlang
● Обработка данных в памяти
● Легко управляемое состояние системы
● Опциональная сериализация в БД
● Централизованная запись
● Упрощенное развертывание (одна
программа)
● Смена привычек (выкинуть delayed_job)
● Одна из самых совершенных VM

26. Как это визуализировать?

27. Веб-интерфейсы
● JS + HTML + HTTP API
● Erlang + Bootstrap (Nitrogen)

28. Nitrogen
● Выбор для админского интерфейса
● Ни строчки JS
● Всё управление с сервера
● DSL не только для генерации, но и для
модификации
● Активное состояние страницы

29. Проблемы Erlang
● Беда с ORM (на уровне Rails 0.5)
● Бизнес-код очень говорливый
● Непривычные логи

30. Резюме
● Рельсы очень круто
● Иногда не очень
● Иногда Eventmachine спасает
● Иногда нет
● Тогда может спасти эрланг
● Подключенные клиенты, C100K и т.п.

31. Вопросы?
Макс Лапшин
max@maxidoors.ru