Erlang&rails

43,393 views

Published on

2 Comments
12 Likes
Statistics
Notes
No Downloads
Views
Total views
43,393
On SlideShare
0
From Embeds
0
Number of Embeds
37,869
Actions
Shares
0
Downloads
29
Comments
2
Likes
12
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Erlang&rails

    1. 1. ERLANG & RAILS Зачем рельсовику Erlang Макс Лапшин. max@erlyvideo.org 2011
    2. 2. Этот доклад о томзачем рельсовику знать Erlangкакие задачи Erlang решает лучше и удобнее чем Railsпочему Erlang, а не Scala/Node.js и прочая фигня
    3. 3. Сетевой демон 80-хНаписан на CКошмарен в отладкеЧрезвычайно сложный failover и балансировкаТребует дорогих программистовРаботал с концепцией подключенного пользователя
    4. 4. Реалии 90-хИндустрия платного показа картинокКастомизация кода под разные бизнесыНовый класс программ: сайты
    5. 5. PHP («запрос-ответ»)Простой язык программированияВсе проблемы с ресурсами решаются схемой «запрос-ответ»Программа живет максимум 2000 мсСложности с персистентными соединениями
    6. 6. Модель «запрос-ответ»Никакой сборки мусораНикакого управления ресурсамиНикакой обработки ошибокГарантированная однопоточностьОткрытие ресурсов на каждом запросеИнициализация кода на каждом запросе
    7. 7. RailsДоведенный до совершенства PHPПо одной копии программы на ядро с последовательнойобработкой запросовСборка мусораНо всё равно это «запрос-ответ»Stateless
    8. 8. Проблемы RailsНельзя отложить выполнение кода после ответаФоновое выполнение кода (delayed job и его ужасы)Огромное потребление памяти на один запросДорогая обработка длинных запросов и сетевыхподзапросов (http-вызовов)
    9. 9. Отсутствие возможности выполнить кодвне схемы «запрос-ответ»
    10. 10. А веб тем временем меняется
    11. 11. Интерактивный вебКаналы передачи данных по инициативе сервераМного долгоживущих соединенийБольший объём фоновой работыЖелезо тоже на месте не стоит (128 ядер уже в продаже)
    12. 12. Мобильные приложенияКоммуникации с iPhone приложениямиAndroid push (один вызов на каждое устройство)Много интеграции сетевых сервисов
    13. 13. Facebook и клоныHTTP дорос до того, что бы массово заменить CorbaЧасти подсистемы общаются по HTTP APIТребуются механизмы контроля за частотой и объёмомвызовов с клиентской стороны
    14. 14. Технические сложностиСхема с одним процессом на соединение не работаетМноготредное программирование — кошмарФреймворки на коллбеках — кошмарВозникает проблема обработки ошибок и контроляресурсов
    15. 15. ErlangНе академическая поделка типа Scala и не сырая поделкахипстеров от программированияРазрабатывается и обкатывается в телеком оборудованииДизайнился не за выходные, как JS, а несколько летEricsson и Бобук пытались отказаться от него — неполучилось
    16. 16. Erlang пригоден для:Comet/WebsocketsАгрегация сетевых вызовов (facebook/vk)Интеграции с не-HTTPMemory state
    17. 17. CometДолгоживущие HTTP-запросы: сервер посылает ответ вмомент генерации данныхКаждый запрос авторизуется по логике приложения ирегистрируется на получение сообщений определенноготипаПроблема в роутинге сообщений, который специфичен дляконкретного сайта1 000 000 открытых сессий — не предел
    18. 18. Агрегация запросовПока Rails делает HTTP-запрос, всё стоит и ждетНа Erlang можно сделать 10 000 параллельных HTTP-запросов и даже не заметить этогоFacebook приложения, Android pushЛегко делаются параллельные вызовы с таймаутами
    19. 19. Интеграция с не-HTTPКонечно же Jabber!SMTP/POP3LDAPИ прочие statefull сетевые протоколы, данные из которыхнужны на HTML-страничке
    20. 20. Memory stateИгрыЧатыПрочая realtime коммуникация пользователей
    21. 21. Memory stateЗадача — сберечь базу данных и уменьшить задержкуУбрать ненужные чтения и записи в БДОтдавать ответы из локального кеша в памяти, а не из базыОбрабатывать данные в локальном кеше
    22. 22. Memory stateОчень проблемно, если писать на Ruby/Java и т.п.Утекание памятиУтекание ресурсов (открытые файлы)Обработка ошибок становится важнейшей задачейМоментально пропадает ощущение bulletproof
    23. 23. Memory state & ErlangВместо тредов процессы (сотни тысяч)Между ними нет общей памятиКоммуникация процессов и таймауты через сообщенияЭффективное использование многоядерностиОчень эффективный сетевой стекНемутабельные значения
    24. 24. Memory state & ErlangЯзык высокого уровня (не C, примерно в 10 раз корочеJava)Вместо лапши из асинхронных (сетевых)вызовов — обычные вызовы функцийЭффективные средства тестирования (fuzzy testing)Полный контроль за состоянием системы включаяконсоль внутри сервера
    25. 25. Memory state & ErlangОшибка в обслуживании одного клиента не обваливаетвесь серверНе требуется писать код для обработки ошибокВсе и ресурсы освобождаются с закрытием процесса
    26. 26. Erlang лучше чем:Java потому что при той же скорости гораздо читаемейRuby потому что эффективно использует ресурсыNode.js потому что построен не на коллбекахВсех вместе своей обработкой ошибок и простотой
    27. 27. Memory state & ErlangКаждый пользователь — отдельный процессКоммуникация пользователей — посылка сообщенийОбщие данные в процессах-агрегаторахОбновление кода без отключения пользователей
    28. 28. РезультатыWooga: с 5 млрд SQL запросов до 5 млнУменьшение парка серверов в несколько разУменьшение времени ответа
    29. 29. РезюмеВеб меняется в сторону большей интерактивностиНадо работать с мобильными приложеними и соц-сетямиУ Rails есть технические проблемы, связанные с дизайномErlang их решает

    ×