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

1,492 views

Published on

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

  • Be the first to comment

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

  1. 1. Там, где рельсы не справляются Макс Лапшин max@maxidoors.ru
  2. 2. Как делали веб в древности? ● Программы на С ● Кошмар и ужас ● Баснословно долго и дорого ● Сплошные велосипеды ● Перл немножко облегчил
  3. 3. Мир веб-приложений (PHP) ● малое время жизни программы ● нет контроля за ресурсами ● share nothing ● внешняя персистентность (Mysql) ● запрос-ответ ● очень удобно делать магазинчики! ● сборка мусора? Не слышали о таком
  4. 4. Rails ● Всё то же самое, но в совершенстве ● Самое правильное расслоение ● Самый читаемый код ● Web 1.5
  5. 5. Веб меняется ● Растут нагрузки ● Запрос-ответ,ответ,ответ ● Просто ответ, ответ, ответ
  6. 6. Масштабируемся железом? 20 мс CPU на обработку запроса 8 ядер 400 RPS — максимум
  7. 7. Масштабируемся железом? Если запросы дергают сеть, то при 100 МБ на воркер и 32 ГБ, лимит по памяти — 300- 500 одновременных соединений
  8. 8. C10K? Не слышали
  9. 9. C100K, C1M? Можно забыть
  10. 10. Масштабируемся железом? Расти с 10 до 100 серверов ок Расти со 100 до 1000 серверов — не ок
  11. 11. Что лимитирует производительность? ● Память ● CPU ● Ненужные обращения к ресурсам
  12. 12. Что с запросами и ответами? ● Сервер теперь сам шлет данные клиенту ● Подключенные клиенты (!) ● Состояние в памяти (!) ● Все достижения PHP рушатся как карточный домик
  13. 13. Как бы так обслуживать клиентов из одной копии программы?
  14. 14. Варианты ● Eventmachine ● Twisted ● Node.js
  15. 15. Проблемы ● Управление ресурсами ● Обработка ошибок ● Управление ресурсами ● Контроль нагрузки ● Управление ресурсами ● Управление ресурсами
  16. 16. Ресурсы ● Память ● Внешние соединения ● Память ● Локальное железо (диски и т.п.) ● Память
  17. 17. Внезапно вы можете перегрузить собственный сервер!
  18. 18. Ошибки ● Как обрабатывать? ● Как отпускать ресурсы? ● Как освобождать память?
  19. 19. Утечка ресурсов — бич долгоживущей программы
  20. 20. Контроль нагрузки ● Глубокая тема ● Надо уметь говорить нет: HTTP 503 ● Иногда лучше подольше, да понадежнее ● Back pressure
  21. 21. Erlang ● четкий ● резкий
  22. 22. Erlang ● multicore ● изоляция данных, клиентов и проблем ● удобный само-мониторинг ● концепция процессов
  23. 23. Где может пригодиться? ● онлайн игры ● pub/sub, кометы и прочие мессенеджеры ● брокеры рекламы, ссылок и т.п. ● долгоживущие серверные задачи ● прочие in-memory API сервисы
  24. 24. Ruby/Python ● Привычно ● Нет multicore ● Кооперативный шедулинг ● Единая память ● stop-world GC ● плохая интроспекция Erlang ● Отлежавшаяся технология ● true multicore ● вытесняющий шедулинг ● нет пауз в GC ● hot code reload ● изоляция ресурсов и ошибок ● интроспекция
  25. 25. Erlang ● Обработка данных в памяти ● Легко управляемое состояние системы ● Опциональная сериализация в БД ● Централизованная запись ● Упрощенное развертывание (одна программа) ● Смена привычек (выкинуть delayed_job) ● Одна из самых совершенных VM
  26. 26. Как это визуализировать?
  27. 27. Веб-интерфейсы ● JS + HTML + HTTP API ● Erlang + Bootstrap (Nitrogen)
  28. 28. Nitrogen ● Выбор для админского интерфейса ● Ни строчки JS ● Всё управление с сервера ● DSL не только для генерации, но и для модификации ● Активное состояние страницы
  29. 29. Проблемы Erlang ● Беда с ORM (на уровне Rails 0.5) ● Бизнес-код очень говорливый ● Непривычные логи
  30. 30. Резюме ● Рельсы очень круто ● Иногда не очень ● Иногда Eventmachine спасает ● Иногда нет ● Тогда может спасти эрланг ● Подключенные клиенты, C100K и т.п.
  31. 31. Вопросы? Макс Лапшин max@maxidoors.ru

×