Статья ни о чем. Краткий обзор 3-х продуктов.
такие статьи тоже нужны
G72K
Roman
Alexander
да, плюсую. толковых обзорных статей мало
Aleksey
Особенно шторм
Sergei
Ну как сказать... Статья мало того что перевод, так и в целом не сравнивает напрямую эти продукты. Где таблицы, где производительность, где боль продакшна?
Vladimir
Роман
Igor
мне он всегда мудаком казался
Роман
Это ортогональное понятие :) Мудак может быть как крутым, так и лохом, как умным, так и тупым, как хозяином, так и рабом...
nvkv
Это ортогональное понятие :) Мудак может быть как крутым, так и лохом, как умным, так и тупым, как хозяином, так и рабом...
умный мудак эквивалентен двум пожарам
Mark ☢️
Mark ☢️
И лох-мудак
Vitaliy
народ а не видел кто чатик про продукты хашикорпа ?
в hangops слаке (англоязычном) об этом много
Denys 💛📈
https://t.me/ru_hashicorp
Denys 💛📈
Только завели
Dmitrii
Мне определенно нравится первое правило.
Aleksey
Мне определенно нравится первое правило.
ну вот на канале докера не стоит ругаться. и к чему это привело ? к брутальному докеру.
Alexey
> ru_hashicorp
> Мат - разрешен.
Да, там было бы сложно без мата
Alexander 🐕
> ru_hashicorp
> Мат - разрешен.
Да, там было бы сложно без мата
Добро пожаловать в удивительный мир языка Golang и набора logical fallacies
Alexander 🐕
Да и вообще привет
Alexey
ну молго быть хуже -- его могли на питоне или руби написать =)
Alexey
и да, привет =)
Serghei
Привет ребята.
У меня вопрос по очередям. Может мы что-то не то делаем..
Изначально у нас был Resque, который в общем-то быстр своим редисом, но в остальном не фонтан - приходится подымать целый аплийкейшн чтоб отработал воркер. Это дорого и не производительно. А учитывая что у нас дофига где PHP, то с php-resque вообще грусть. Сам проект в полу заброшенном состоянии. Форкать и допиливать поделие которое и так уже форк да и к тому же не самое лучшее то еще удовольствие. В целом нас интересует быстрая публикация сообщений. По большому счету типичный юзкейс который мы рассматриваем - создали конект, бросили сообщение, закрыли коннект, закончили работу. У нас просто нет такого когда мы при на один коннект бросаем очень много сообщений. Конвейер ,если необходим, в каждом случае реализуем своими силами.
Послушали народ про то что крутые пацаны в 21 веке используют rabbit. И потеряли 3 недели зря на внедрение. Что php что java тратят много времени а оверхед самого протокола. В мельникг листе пишут:
> One-connection-per-message is not how RabbitMQ or messaging protocols are supposed to be used. The best you can do with PHP is to increase TCP backlog and possibly send buffer size and batch messages. Or just don't use PHP if you can.
C Java те же грабли. Я написал некоторое кол-во тестов с использованием C и различных PHP билиотек - мы реально тратим 60 миллисекунд на коннект с сервером. Разумеется нас интересуют персистентные очереди в кластере нод, за балансером с включенным авто-кластером. Я тестировал вообще все виды комбинаций. Самое быстрое решение - 1 Rabbit нода в локалхосте, там же где и апликейшн (но у нас и тонна) - 60 миллисекунд. Были комбинации теста когда на коннект уходило 170 миллисекунд. Паблишинг сообщения тоже не фонтан.
На ZeroMQ даже не смотрим - у нас куча говнорей. Вообще тонна. Учитывая что с ZeroMQ все придется делать самому - мы с ним однозначно хлебнем. Да и опять же - предвижу с AMQP здесь те же проблемы. Протокол же один. Смотрели и на ActiveMQ, которое больше для Java мира. Но я лично почти уверен что новые проекты на нем не стоит начинать. Те компании которые его используют - либо госсектор, либо так исторически сложилось.
На Си с RabbitMQ все проще - 3 миллисекунды. Это то, что нам нужно на самом деле. Но на C это сложно интегрировать. Рассматривали вариант php-расширения, но на Си пишут раз два и обчелся. Некому по большому счету будет это поддерживать.
В качестве сравнения тестировали SQS - там вообще тихий ужас. 3 http запроса чтоб опубликовать сообщение.
Serghei
В целом нам хотелось бы иметь зрелое решение для nodejs, php, java и go
Serghei
И вот, вопрос, насколько ,как вы считаете, резонно расматривать nats?
Serghei
Просто по нашим собственным замерам nats обскакал все что только мы пробовали
Serghei
php клиент для nats публикует сообщения и конектится быстрее чем c-клиент для rabbit например
Serghei
Лично я про него ничего не слышал. Понятное дело можно почитать в интернетиках. Но может уже кто-то с ним сталкивался и есть success/bad story?
ASTASHOFF
тоже в эту сторону смотрел, описания его понравились, но пока еще нигде не имплементил. Во всяком случае, как только понадобится что-то подобное в новой конфигурации, натс - первый кандидат
ASTASHOFF
вообще лично я почему начал смотреть в сторону натс изначально - в AMQP самом вроде как все рулить должен паблишер
ASTASHOFF
а хотелось бы фильтровать сообщения на брокере, тем более когда у нас много паблишеров в этот фифо пишет, и если от "правильности" сообщений в очереди зависит стабильность consumer'a
ASTASHOFF
ведь обычные amqp брокеры не шибко мудреные (не уверен, знаю что в nsq так), сам протокол предполагает только очередь и раздачу сообщений подписчикам
ASTASHOFF
да и имплементацию на го тоже можно в плюс отнести
Serghei
угу
ASTASHOFF
а sqs это же вендор лок?
ASTASHOFF
зачем такую важную часть инфраструктуры привязывать к какому-то хостед сервису
Serghei
а у нас и так весь с тек в амазоне
Serghei
что кластер с ребитом, что кластер с натсом
ASTASHOFF
хостинг на каком-то провайдере это не такой вендор лок как какой-то паблишинг сервис с использованием их sdk в своем софте
ASTASHOFF
в конце концов, инфраструктуру можно перенести. а если на уровне софта еще куча зависимостей
Vladimir
зачем такую важную часть инфраструктуры привязывать к какому-то хостед сервису
Люди считают что так проще - не делать самим, а взять готовое за денюжку
ASTASHOFF
им же выгодно это, учитывая их далеко не блестящую оптимальность по сравнению с другими клауд провайдерами
ASTASHOFF
потом больнее будет
Denis 災 nobody
Есть продукт, есть продажи
ASTASHOFF
если говорить о очереди, то неужели заимплементить sqs будет прям быстрее, нежели поднять свой брокер?
ASTASHOFF
тот же nsq очень быстр и кластеризируется
Serghei
в любом случае sqs тестировали что бы иметь более полную картину
Aleksey
Nsqd доволен. К unordered и at least once готов.
G72K
И вот, вопрос, насколько ,как вы считаете, резонно расматривать nats?
а там время на коннект не тратится чтоли?
Serghei
2 мс
G72K
можете хранить пул коннектов в демоне персистентном и кидать в сообщения в него, а он уже по установленному коннекту отошлет куда надо
G72K
тогда из php все коннекты будут внутри локалхоста. но это костыль наверно.зато можно выбирать технологию не по времени коннекта, а по другим параметрам
Alexander
можете еще тред держать с соединением, в него кидать сообщения как получиться, а вообще 60ms на конект как то много у вас сервера далеко или tls?
Serghei
можете хранить пул коннектов в демоне персистентном и кидать в сообщения в него, а он уже по установленному коннекту отошлет куда надо
Рассматривали вариант. Но коробночного решения или нет или оно не на поверхности. Хотели писать даже что-то свое, на том же C. Но если писать свою проксю, то почему не использовать сразу Сишный клиент и не обернуть его в PHP-расширение?
Serghei
можете еще тред держать с соединением, в него кидать сообщения как получиться, а вообще 60ms на конект как то много у вас сервера далеко или tls?
Я изначально на это и грешил и разумеется мы провели серию тестов. 60 ms это самый лучший вариант потому что это локалхост, та же машина где и тест. Варианты с другим сервером/регионом/амазоном еще хуже. Опять же, с Си например таких проблем нет. Что локально, что в амазоне. На том же Python таких проблем нет. Но Python у нас почти нет.
Serghei
Я допускаю, что есть что-то еще, что я не заметил, не проверил. Может быть по умолчанию какая-то настройка включена "дорогая". Но мы всякое перепробовали и технически сдались, не найдя что еще можно подкрутить.
Serghei
По этому я сюда и написал )
Serghei
Есть вот такой даже список:
• Use a larger prefetch count. Small values hurt performance.
• A topic exchange is slower than a direct or a fanout exchange.
• Make sure queues stay short. Longer queues impose more processing overhead.
• If you care about latency and message rates then use smaller messages. Use an efficient format (e.g. avoid XML) or compress the payload.
• Experiment with HiPE, which helps performance.
• Avoid transactions and persistence. Also avoid publishing in immediate or mandatory mode. Avoid HA. Clustering can also impact performance.
• You will achieve better throughput on a multi-core system if you have multiple queues and consumers.
• Use at least v2.8.1, which introduces flow control. Make sure the memory and disk space alarms never trigger.
• Virtualisation can impose a small performance penalty.
• Tune your OS and network stack. Make sure you provide more than enough RAM. Provide fast cores and RAM.
Serghei
Все это, в разных комбинациях тестировали
Dmitry
кто тут борг попячил?
Dmitry
оно в с3 как я понял из коробки не умеет?
Anton
И вот, вопрос, насколько ,как вы считаете, резонно расматривать nats?
потыкайте в натс, он хороший :)
G72K
Кто-нибудь знает примеры тестов для инфрастуктуры? Желательно гибко, от настроек облака, до проверок что какой нибудь файлик присутствует на каждой седьмой машине. rerun не предлагать, хочется больше батареек :)
Aleksey
goss/testinfra/serverspec
Roman
в итоге это скомилируется в тот же код на си, но на зефире писать проще по идее. почти тот же пхп
Serghei
а может написать php расширение на основе зефира? https://docs.zephir-lang.com/en/latest/welcome.html
Разумеется могу, учитывая что я в Zephir Core Team :)
Serghei
udp не подходит по причинам описаным выше, типа персистентности и пр.
Serghei
каждое сообщение важно. очень
Denis 災 nobody
udp с контролем доставки не?
Denis 災 nobody
типа принял - отправил udp что ок, отправитель удалил из отправки
Sergei
типа принял - отправил udp что ок, отправитель удалил из отправки
что-то мне это напоминает...
niko
удп с контролем доставки, узнаю девопсов)
Vladislav
😀
Denis 災 nobody
udp-based vpn?