Там, где Rails не справляются

Там, где рельсы несправляются

Макс Лапшинmax@maxidoors.ru

Как делали веб в древности?

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

Мир веб-приложений (PHP)

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

Rails

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

Веб меняется

● Растут нагрузки● Запрос-ответ,ответ,ответ● Просто ответ, ответ, ответ

Масштабируемся железом?

20 мс CPU на обработку запроса8 ядер400 RPS — максимум

Масштабируемся железом?

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

C10K?

Не слышали

C100K, C1M?

Можно забыть

Масштабируемся железом?

Расти с 10 до 100 серверов окРасти со 100 до 1000 серверов — не ок

Что лимитирует производительность?

● Память● CPU● Ненужные обращения к ресурсам

Что с запросами и ответами?

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

карточный домик

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

Варианты

● Eventmachine● Twisted● Node.js

Проблемы

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

Ресурсы

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

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

Ошибки

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

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

Контроль нагрузки

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

Erlang

● четкий● резкий

Erlang

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

Где может пригодиться?

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

Ruby/Python

● Привычно● Нет multicore● Кооперативный

шедулинг● Единая память● stop-world GC● плохая

интроспекция

Erlang

● Отлежавшаяся технология

● true multicore● вытесняющий

шедулинг● нет пауз в GC● hot code reload● изоляция

ресурсов и ошибок● интроспекция

Erlang

● Обработка данных в памяти● Легко управляемое состояние системы● Опциональная сериализация в БД● Централизованная запись● Упрощенное развертывание (одна

программа)● Смена привычек (выкинуть delayed_job)● Одна из самых совершенных VM

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

Веб-интерфейсы

● JS + HTML + HTTP API● Erlang + Bootstrap (Nitrogen)

Nitrogen

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

модификации● Активное состояние страницы

Проблемы Erlang

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

Резюме

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

Вопросы?

Макс Лапшинmax@maxidoors.ru