erlyvideo Sep 2 2012 at 22:44

Comet сервер на эрланге

5 min

8.6K

Erlang/OTP*Website development*

+40

Comments 34

keylase Sep 2 2012 at 23:38

Подскажите, пожалуйста, существуют ли реализации комбинированного сервиса comet (long polling) + websockets?

erlyvideo Sep 2 2012 at 23:40

Да, ковбой это может делать, об этом будет во второй части.

MechanisM Sep 2 2012 at 23:45

Если вас интересует еще и что-то вне Erlang, тогда есть модуль для nginx с таким функционалом.

erlyvideo Sep 2 2012 at 23:47

Тут дело какое: если вам потребуется приделать к этому авторизацию через mysql/постгрес, то усилия, требуемые что бы грамотно заимплементить модуль для nginx будут несравнимы с аналогичным кодом на эрланге.

MechanisM Sep 2 2012 at 23:51

Совершенно согласен, я просто как вариант навскидку вспомнил, и написал. А сфера применения бывает разная — где-то и не требуется авторизация.

VBart Sep 3 2012 at 14:11

Потребуется максимум час, если вы ранее были не знакомы с lua. Модуль postgresql к nginx уже есть, далее дело за малым.

p.s. ничего против erlang не имею, он хороший.

erlyvideo Sep 3 2012 at 14:21

Оставляя в стороне вопросы удобства самого языка, erlang отличается от lua/javascript/ruby/etc концепцией разделяемой между процессами памяти. Это меняет практически всё.

VBart Sep 3 2012 at 14:33

«Практически всё» — это что именно? В nginx тоже есть резделяемая память, и модуль lua содержит достаточно удобный интерфейс к ней.

Drinker Sep 3 2012 at 07:26

Да, существует
github.com/extend/bullet

Joes Sep 3 2012 at 15:10

Да, SockJS.

Есть сервер для эрланга, работает тоже поверх ковбоя: github.com/sockjs/sockjs-erlang

MechanisM Sep 2 2012 at 23:46

Реалтайм работающий на Erlang это всегда хорошо(часто лучше и стабильнее чем NodeJS) и нареканий не возникает.
Я вот только еще учу Erlang. Большое спасибо за пост!

kliss Sep 3 2012 at 00:31

Пфф, да всё что угодно лучше и стабильнее node.js. Даже PHP :)

MechanisM Sep 3 2012 at 00:58

PHP в плане создания реалтайма лучше чем NodeJS?

VolCh Sep 3 2012 at 01:23

А что вы имеете в виду под реалтаймом? Помнится из лекций, что это гарантированное время ответа на запрос.

MechanisM Sep 3 2012 at 01:44

Это когда «ответ» приходит без запроса, а когда произошло например какое-то событие.
Тоесть клиенту не надо систематически опрашивать сервер не изменилось ли что, а просто зарегистрировался/подписался и в ожидании событий и соответсвенно уведомлений о них.

VolCh Sep 3 2012 at 01:55

Для меня это просто двухсторонний протокол обмена информацией, server push, comet.

Не знаю, лучше PHP или JS (сравнивать язык с фреймворком вообще некорректно, кстати), но на PHP это реализовать можно, в том числе асинхронно, без форка процесса каждому клиенту. Но над выбором на чем реализовывать сервер-сайд для вебсокетс сам думаю. PHP знаю ~~хорошо~~ лучше других языков, JS — похуже, Erlang — только осовы синтаксиса. А ещё в сторону Ruby с EventMachine смотрю.

MechanisM Sep 3 2012 at 02:10

Ну да, я слышал что «на PHP можно» но чтобы это было лучше и стабильнее чем на NodeJS? — я в этом сомневаюсь.
Вот те-же Вконтакте — сайт на php а xmpp сервер для сообщений написали на NodeJS,
Facebook на php(ну да и hiphop) а сообщения работают насколько я знаю через Ejabberd(Erlang) — даже проекты написанные на php не пишут реалтйм на php.
Да-да Ruby и его EventMachine это тоже то что я подразумевал под реалтаймом.

VolCh Sep 3 2012 at 02:15

xmpp — да, но вот уведомления от приложений или о новом сообщении при просмотре обычных страниц тоже на nodejs у VK?

seriyPS Sep 3 2012 at 22:07

где-то читал что уведомлялка long-polling у них на C

int03e Sep 3 2012 at 03:14

Макс, спасибо, надеюсь что история получит продолжение.

quantum Sep 3 2012 at 05:01

При написании статьи есть кнопочка «Предпросмотр», она нужна для того, чтобы в опубликованной статье не было таких артефактов:

< code>
./rebar compile

quantum Sep 3 2012 at 05:04

</code>

erlyvideo Sep 3 2012 at 09:01

В хабре какой-то глупый парсер HTML-я, который оказался не в состоянии обработать pre и code подряд.

Увы, но это проблема хабра, отдельно под него править статью я не готов.

kliss Sep 3 2012 at 09:46

Так ты статью для другого места писал вообще? :)

erlyvideo Sep 3 2012 at 11:40

Конечно.

jov Sep 3 2012 at 12:33

Хотя может и здесь кросспост и ресурс для которого писалась эта статья нам так и не найти.

w495 Sep 10 2012 at 17:57

Макс, оформи код, пожалуйста, через

<source lang="erlang">
    foo(X)-> {bar, X}.
</source>

А то читать, ну совсем тяжело, ни тут, ни в жж.

w495 Sep 10 2012 at 23:22

Спасибо!

akalend Sep 3 2012 at 17:48

Макс — спасибо :)
потихоньку точу Эрланг…
пишу лонг-пулл на Сях, работает стабильно

erlyvideo Sep 3 2012 at 18:34

Можно написать на эрланге — время на обучение и написание растворится на фоне времени на написание хорошего, нетекущего сервера на С =)

w495 Sep 10 2012 at 19:50

Смотря как писать. Имхо, для некоторых задач подходит написание интерпретатора своего специфического языка (flex, bizon помогут), и написание сервера на этом специфическом языке. Правда нам было лень писать его на С, и мы написали на erlang.

erlyvideo Sep 10 2012 at 19:52

Вот ты лучше расскажи про ваш опыт. Что у вас написано: видеораздача или сайт? Чего интересного было?

w495 Sep 10 2012 at 23:13

Ну это похоже на то, о чем говорил Боб Ипполито на конфе в Яндексе. Правила отбора рекламы. В неформальной постановке правила оказались настолько сложными (а мы таки заботимся, чтобы пользователь не посмотрел слишком много рекламы), что для их формализации пришлось написать маленький интерпретатор lisp-подобного языка. По сути это просто набор фильтров. Но фильтры имеют строк действия, условия срабатывания, их можно складывать, вычитать, проводить операции как над множествами.

Из интересного:

Интерпретатор не стал бутылочным горлышком, хотя мы этого ожидали. Скорость работы все равно упиралась только в базу (до его подключения упиралось в нее же).

Офтоп:

Во общем не удивительно, c одной стороны. Когда я тестировал erlang (R15 c HiPE) в другом проекте (http://www.slideshare.net/w-495/dsmts-diplomatext, отчати github.com/w495/ngrm-smt), то скорость была сопоставима с C. (Но, без HiPE, к сожалению, нет) Глобально сравнивал с Moses на тех же исходных данных с минимальными настройками для Moses. Локально, на сопственных сишных поделках. От питона, который, в силу обстоятельств, мы вынуждены поддерживать такого ожидать трудно (github.com/w495/ngrm-emt). ngrm-smt и ngrm-emt делают разные вещи, но ngrm-smt включает в себя часть функционала ngrm-emt.
Я лично для себя познал всю мощь функций высшего порядка (lists:map, lists:filter и пр) и нативных функций работы со списком тегированных туплов (lists:key*), ибо размер кода они сильно уменьшили. В первой версии интерпретатора все писалось в стиле:
```
    handle_list([], Info, Opts) ->
        Info.
    handle_list([Param|Parms], Info, Opts)-> 
       Res = handle_item(Param),
       handle_list(Parms, [Res|Info], Opts).
```
Как мне казалось, это эффективнее, чем передавать fun'ы. Но выглядело как нагромождение, чего-то несуразного, тяжело поддерживаемого. На скорость по моим замерам это не повлияло (всего скорее, повлияло на самом деле, но незначительно).
Очередной раз убедились, что написание интерпретаторов на функциональных языках — не особо сложная задача. Даже при постоянно меняющихся требования. Первый раз я в этом убедился, когда за ночь написал компилятор обрезанной версии питона на lisp, еще в универе. Тогда это представлялось какой-то игрушкой. Но как оказалось подобные вещи весьма полезны. Вообще как, было написано, по-моему и М. Сипсера, чтобы решить проблему, достаточно правильно сформулировать язык ее описания. Ну вот мы и получили подтверждение.

Да, к сожалению, вслед за Бобом Ипполито, код предоставить вам не смогу. Придется поверить мне на слово.

w495 Sep 10 2012 at 23:14

На тему языка, сейчас работаем над еще одним внутренним проектом, для которого, как мне сейчас кажется, крайне подошел бы такой специализированный язык. Надеюсь мое мнение разделят другие разработчики. Ибо сейчас это начинает превращаться в кашу из удаленных вызовов, операций с портами, исправлений проблем mochiweb.