Comments 24
Меня временами терзает один вопрос: почему люди не могу воспринимать советы, рекомендации и чужой опыт бесплатно? Почему нужна платная экспертиза? Нужно участие в платных конференциях и советы от бывалых воротил? Либо, нужен именно свой, печальный опыт. Я часто говорю, что путь к Erlang не может быть прямым, а должен идти через боль и страдания в попытках решить задачи другими инструментами. А ведь я был в Тензоре на собеседовании в конце 2014 года, говорил и с начальником разработки си++ и выше. Рекомендовал Erlang. Помню, как Д. Новиков мне сказал «если ваш Erlang такой хороший, почему же его все не используют?». Похоже, что было не то время, не те обстоятельства и не тот советчик.
Добро пожаловать в Erlang )
Добро пожаловать в Erlang )
+4
А был опыт разработки на Эрланге перед приходом мысли написать свой модуль? Или, хотя бы, хорошие знания о том, что это такое и с чем его едят?
0
Какая задержка в итоге?
0
По моему проще было написать свой сервис на Erlang. Почему все стараются использовать какие-то стандартные решения, а потом адаптируют их костылями под свои нужды?
+1
+1
Был интересный доклад на эту тему на fpconf 2016 — «Почему в вашем следующем проекте вам нужно писать велосипеды на ерланге». Там был сделан велосипед как раз вместо RabbitMQ.
Был интересный доклад на эту тему на fpconf 2016 — «Почему в вашем следующем проекте вам нужно писать велосипеды на ерланге». Там был сделан велосипед как раз вместо RabbitMQ.
0
Здесь всегда два мнения: «зачем изучать и настраивать что-то готовое, ведь проще запилисть своё?» и «зачем изобретать велосипед, если есть готовое?», и выбор зависит от ситуации. На момент старта у нас не было специалистов по Erlang, а RabbitMQ имел всё на борту. За 4 года жизни проекта на фикс проблем ушло наверное не более 2 человекомесяцев.
0
Здесь вопрос не в этом, а в другом: «Я беру черную кробку, представляю как оно работает снаружи, вообще не понимаю как оно работает внутри, думаю что оно мне подходит.» Но потом, оказывается что надо адаптировать, причем внешними каким-то штуками. В конце концов выясняется что 2 месяца одного разработчика надо чтобы сделать простой сервис очередей :)
А вообще, конечно, это ваш старт, и ваше решение.
А вообще, конечно, это ваш старт, и ваше решение.
0
Ну вообще справедливости ради, это хоть и «простой сервис очередей», но это кластерное решение, стабильно работающее под нагрузкой. Отлаженное, проверенное, с документацией, некоторой админкой, гарантированно совместимое с разными клиентами. При этом внутри есть очень много чего, если вдруг понадобится. Если все что надо — малость доработать напильником. Два человека месяца в разрезе вышесказанного — это не так и много. Да и человекомесяцы очень разные бывают.
+1
Дак я ж ничего не имею против стабильного и отлаженного. Ну если вы не умеете готовить Erlang, то пользуйтесь RMQ. Я ж вам не запрещаю.
В данном случае говорилось о конкретном применении, с конкретным кастомным JS клиентом.
Просто моё впечатление о статье — это не как приготовили высокопроизводительный сервис, а как на каждом этапе собирали какие-то узкие места RMQ и обходили их с помощью плагинов, а особенно внутренней структуры сервиса. Хотя по сути, работа любого инженера в ИТ это обход каких-то существующих ограничений на легаси коде.
В данном случае говорилось о конкретном применении, с конкретным кастомным JS клиентом.
Просто моё впечатление о статье — это не как приготовили высокопроизводительный сервис, а как на каждом этапе собирали какие-то узкие места RMQ и обходили их с помощью плагинов, а особенно внутренней структуры сервиса. Хотя по сути, работа любого инженера в ИТ это обход каких-то существующих ограничений на легаси коде.
0
При таком раскладе вообще не надо пользоваться готовыми решениями?
0
То есть, если Вам требуется использовать стороннее открытое решение, то первым делом Вы становитесь профессионалом (а лучше экспертом) в языке, на котором написано данное ПО, а затем его анализируете на идеальность. Причём заранее имеете чёткую задачу, которая никогда не изменятся в будущем. И весь этот труд оплачивается вашей компанией. Так?
Я конечно может отстал от жизни, но обычно если нужно использовать стороннее решение, то проводится его тестирование на пригодность с точки зрения функционала и других требований.
И, следуя Вашей логике, если когда-то в будущем потребуется, скажем, написать какой-то порт на С++ для Erlang, то получается надо было всё сразу писать на С++ согласно вашей фразе: «Почему все стараются использовать какие-то стандартные решения, а потом адаптируют их костылями под свои нужды?».
Я конечно может отстал от жизни, но обычно если нужно использовать стороннее решение, то проводится его тестирование на пригодность с точки зрения функционала и других требований.
И, следуя Вашей логике, если когда-то в будущем потребуется, скажем, написать какой-то порт на С++ для Erlang, то получается надо было всё сразу писать на С++ согласно вашей фразе: «Почему все стараются использовать какие-то стандартные решения, а потом адаптируют их костылями под свои нужды?».
0
> То есть, если Вам требуется использовать стороннее открытое решение, то первым делом Вы становитесь профессионалом (а лучше экспертом) в языке, на котором написано данное ПО, а затем его анализируете на идеальность.
А в чем фишка открытости системы, которую вы используете, если вы не в состоянии поддерживать этот код? В таком случае эффект тот же самый что от закрытого. Пользуйтесь, я не запрещаю
Если вам так действительно сильно нужна поддержка по Erlang, то её всегда можно получить на оутсорсе или фрилансе.
> Причём заранее имеете чёткую задачу, которая никогда не изменятся в будущем.
Как минимум требования должны собираться. А из этого сразу следовало бы что первый вариант самый не очень. Т.е. даже на его реализацию вы сэкономили бы время.
Я то не против использования RMQ, но по моему статья не о том, как вы построили систему, а как собирали слабые стороны RMQ и что-то пытались фиксить, хотя на самом деле достаточно было сделать свою собственную разработку на «все времена». Она бы получилась меньше, и более гибкой.
RMQ он для бедных. Все свойства RMQ вытекают из свойства Erlang. По сути RMQ ничего нового не предлагает, кроме обертки в виде некоего протокола AMQP, ну который достаточно тяжелый для случаев всякого уведомления веб-клиентов.
Попробуйте написать своё решение, я думаю разница производительности будет в 2-3 раза в пользу своего. А объем кода в десятки раз меньше RMQ.
А в чем фишка открытости системы, которую вы используете, если вы не в состоянии поддерживать этот код? В таком случае эффект тот же самый что от закрытого. Пользуйтесь, я не запрещаю
Если вам так действительно сильно нужна поддержка по Erlang, то её всегда можно получить на оутсорсе или фрилансе.
> Причём заранее имеете чёткую задачу, которая никогда не изменятся в будущем.
Как минимум требования должны собираться. А из этого сразу следовало бы что первый вариант самый не очень. Т.е. даже на его реализацию вы сэкономили бы время.
Я то не против использования RMQ, но по моему статья не о том, как вы построили систему, а как собирали слабые стороны RMQ и что-то пытались фиксить, хотя на самом деле достаточно было сделать свою собственную разработку на «все времена». Она бы получилась меньше, и более гибкой.
RMQ он для бедных. Все свойства RMQ вытекают из свойства Erlang. По сути RMQ ничего нового не предлагает, кроме обертки в виде некоего протокола AMQP, ну который достаточно тяжелый для случаев всякого уведомления веб-клиентов.
Попробуйте написать своё решение, я думаю разница производительности будет в 2-3 раза в пользу своего. А объем кода в десятки раз меньше RMQ.
+1
А в чем фишка открытости системы, которую вы используете, если вы не в состоянии поддерживать этот код? В таком случае эффект тот же самый что от закрытого.
Смысл опенсорса же в поддержке сообществом, а не отдельно взятым пользователем.
Если вам так действительно сильно нужна поддержка по Erlang, то её всегда можно получить на оутсорсе или фрилансе.
Так вроде проблем с поддержкой как раз не возникло. Потому и не было смысла пилить свое.
0
Если вам так действительно сильно нужна поддержка по Erlang, то её всегда можно получить на оутсорсе или фрилансе.
Нам поддержка не нужна, мы же как раз и не агитируем писать всё на Erlang с нуля.
но по моему статья не о том, как вы построили систему, а как собирали слабые стороны RMQ и что-то пытались фиксить
Естественно никто не будет фиксить сильные стороны. Мы рассказали о применени конкретного инструмента в нашей практие и как его можно расширить под свои нужны (пользуясь существующим механизмом плагинов) по мере роста потребностей.
Попробуйте написать своё решение, я думаю разница производительности будет в 2-3 раза в пользу своего. А объем кода в десятки раз меньше RMQ.
Безусловно уже смотрели, и выигрышь будет больше, но затраты на разработку пока будут выше, чем профит. Потому-что это не просто нафигачить 500 строк кода, как у человека на видео выше, а делать надо адекватно, с поддержкой многих клиентов, кейсов использования, возможности расширения, всевозможных видов тестирования и интеграцией в CI. Какие-то тестовые испытательные образцы у нас на «4 ядрах» отправляли и по 500-600к/сек.
0
Спасибо, интересно было почитать.
Последний вопрос: какую структуру нам нужно использовать, чтобы уметь проверять существование обменника в списке, удалять его оттуда, а также искать уже просроченные обменники с наименьшими затратами?
Раз уж вы всё равно запускаете erlang процесс, то наиболее разумно было бы использовать для этого ETS-таблицу. Для контейнеров с более чем 100-200 элементов как правило удобнее её использовать. А в случае ordered_set
вы сможете её и для сортировки по таймстемпу использовать.
gb_tree, хорош для нахождения минимального значения (обменника с наименьшим временем истечения срока годности, которое сравниваем с текущим временем), в качестве ключа структура {ExpireTime, Exchange}, а значение равно 0 (не используется).
Если знгачение не используется, то лучше использовать gb_sets
+1
Sign up to leave a comment.
Сервис оповещения миллиона пользователей с помощью RabbitMQ