народ а не видел кто чатик про продукты хашикорпа ?

в hangops слаке (англоязычном) об этом много

https://t.me/ru_hashicorp

Только завели

Мне определенно нравится первое правило.

Мне определенно нравится первое правило.

ну вот на канале докера не стоит ругаться. и к чему это привело ? к брутальному докеру.

И тут дождик

> ru_hashicorp > Мат - разрешен. Да, там было бы сложно без мата

> ru_hashicorp > Мат - разрешен. Да, там было бы сложно без мата

Добро пожаловать в удивительный мир языка Golang и набора logical fallacies

Да и вообще привет

ну молго быть хуже -- его могли на питоне или руби написать =)

и да, привет =)

Darknet - темная сторона всемирной паутины @darknets

Mybitcoin - Блог о Криптовалюте и способах на ней заработать! @faucetclub

Привет ребята. У меня вопрос по очередям. Может мы что-то не то делаем.. Изначально у нас был 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 запроса чтоб опубликовать сообщение.

В целом нам хотелось бы иметь зрелое решение для nodejs, php, java и go

И вот, вопрос, насколько ,как вы считаете, резонно расматривать nats?

Просто по нашим собственным замерам nats обскакал все что только мы пробовали

php клиент для nats публикует сообщения и конектится быстрее чем c-клиент для rabbit например

Лично я про него ничего не слышал. Понятное дело можно почитать в интернетиках. Но может уже кто-то с ним сталкивался и есть success/bad story?

И вот, вопрос, насколько ,как вы считаете, резонно расматривать nats?

думаю - да

тоже в эту сторону смотрел, описания его понравились, но пока еще нигде не имплементил. Во всяком случае, как только понадобится что-то подобное в новой конфигурации, натс - первый кандидат

вообще лично я почему начал смотреть в сторону натс изначально - в AMQP самом вроде как все рулить должен паблишер

а хотелось бы фильтровать сообщения на брокере, тем более когда у нас много паблишеров в этот фифо пишет, и если от "правильности" сообщений в очереди зависит стабильность consumer'a

ведь обычные amqp брокеры не шибко мудреные (не уверен, знаю что в nsq так), сам протокол предполагает только очередь и раздачу сообщений подписчикам

да и имплементацию на го тоже можно в плюс отнести

угу

а sqs это же вендор лок?

зачем такую важную часть инфраструктуры привязывать к какому-то хостед сервису

а у нас и так весь с тек в амазоне

что кластер с ребитом, что кластер с натсом

хостинг на каком-то провайдере это не такой вендор лок как какой-то паблишинг сервис с использованием их sdk в своем софте

в конце концов, инфраструктуру можно перенести. а если на уровне софта еще куча зависимостей

зачем такую важную часть инфраструктуры привязывать к какому-то хостед сервису

Люди считают что так проще - не делать самим, а взять готовое за денюжку

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

потом больнее будет

потом больнее будет

Тут важнее "потом"

Есть продукт, есть продажи

если говорить о очереди, то неужели заимплементить sqs будет прям быстрее, нежели поднять свой брокер?

тот же nsq очень быстр и кластеризируется

в любом случае sqs тестировали что бы иметь более полную картину

Nsqd доволен. К unordered и at least once готов.

И вот, вопрос, насколько ,как вы считаете, резонно расматривать nats?

а там время на коннект не тратится чтоли?

2 мс

можете хранить пул коннектов в демоне персистентном и кидать в сообщения в него, а он уже по установленному коннекту отошлет куда надо

тогда из php все коннекты будут внутри локалхоста. но это костыль наверно.зато можно выбирать технологию не по времени коннекта, а по другим параметрам

можете еще тред держать с соединением, в него кидать сообщения как получиться, а вообще 60ms на конект как то много у вас сервера далеко или tls?

можете хранить пул коннектов в демоне персистентном и кидать в сообщения в него, а он уже по установленному коннекту отошлет куда надо

Рассматривали вариант. Но коробночного решения или нет или оно не на поверхности. Хотели писать даже что-то свое, на том же C. Но если писать свою проксю, то почему не использовать сразу Сишный клиент и не обернуть его в PHP-расширение?

можете еще тред держать с соединением, в него кидать сообщения как получиться, а вообще 60ms на конект как то много у вас сервера далеко или tls?

Я изначально на это и грешил и разумеется мы провели серию тестов. 60 ms это самый лучший вариант потому что это локалхост, та же машина где и тест. Варианты с другим сервером/регионом/амазоном еще хуже. Опять же, с Си например таких проблем нет. Что локально, что в амазоне. На том же Python таких проблем нет. Но Python у нас почти нет.

Я допускаю, что есть что-то еще, что я не заметил, не проверил. Может быть по умолчанию какая-то настройка включена "дорогая". Но мы всякое перепробовали и технически сдались, не найдя что еще можно подкрутить.

ERROR: S client not available

По этому я сюда и написал )

Есть вот такой даже список: • 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.

Все это, в разных комбинациях тестировали

кто тут борг попячил?

оно в с3 как я понял из коробки не умеет?

И вот, вопрос, насколько ,как вы считаете, резонно расматривать nats?

потыкайте в натс, он хороший :)

Кто-нибудь знает примеры тестов для инфрастуктуры? Желательно гибко, от настроек облака, до проверок что какой нибудь файлик присутствует на каждой седьмой машине. rerun не предлагать, хочется больше батареек :)

goss/testinfra/serverspec

Привет ребята. У меня вопрос по очередям. Может мы что-то не то делаем.. Изначально у нас был 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 запроса чтоб опубликовать сообщение.

а может написать php расширение на основе зефира? https://docs.zephir-lang.com/en/latest/welcome.html

в итоге это скомилируется в тот же код на си, но на зефире писать проще по идее. почти тот же пхп

а может написать php расширение на основе зефира? https://docs.zephir-lang.com/en/latest/welcome.html

Разумеется могу, учитывая что я в Zephir Core Team :)

Привет ребята. У меня вопрос по очередям. Может мы что-то не то делаем.. Изначально у нас был 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 запроса чтоб опубликовать сообщение.

Gelf udp

udp не подходит по причинам описаным выше, типа персистентности и пр.

каждое сообщение важно. очень

udp с контролем доставки не?

типа принял - отправил udp что ок, отправитель удалил из отправки

типа принял - отправил udp что ок, отправитель удалил из отправки

что-то мне это напоминает...

удп с контролем доставки, узнаю девопсов)

?

udp-based vpn?

udp не подходит по причинам описаным выше, типа персистентности и пр.

А не пофиг ли что там внутри? Напишите API к вашей очереди. Сделайте из него сервис. Сервис держит тредпул коннектов к очереди. Вы общаетесь с сервисом как угодно. Можно его поставить на туже машину, что и ваше пхп, общаться по localhost или unix domain socket. Можно вынести на отдельную машину, общаться по RPC (для него же персистентный коннекшн пул). Если очень хотеть можно RPC сделать UDP-based, но с reqest-response и ретраями (как DNS), но оно должно быть идемпотентно тогда и будет иметь ограничение на размер сообщения (если вы не хотите реализовыват свой транспортный протокол поверх с фреймингом и балеринами). Если язык только один (пхп я так понимаю) можно сделать "толстого клиента" и сделать библиотеку из сервиса, API станет вызовом фунции, коннекшн пул к оцереди должен быть общий на php процесс, соединения должны возвращаться обратно в пул на выходе клиента из скоупа (вместо того чтобы убиваться, так делают все базы данных). Заметьте что ничего из выше перечисленного не зависит от того какая там очередь врутри. В этом и смысл абстракций.

что-то мне это напоминает...

utp

гоняет кто одновременно openvz+kvm? у нас тут вообще мистика

хостнода - центос 6.9, 64 гига рамы. openvz машинка - выделено 16 гиг рамы, говорит "память кончилась", по факту занято там менее гига. Делаем vzctl set 105 —ram 2G - и ООМ прибивает 2 kvm машины!