Pull to refresh

Comments 12

А замеры? Графики? Получилось лучше/быстрее, чем амазоновский SQS?

Да, проводили замеры. Пока получилось, что мы немного быстрее, чем Амазон, на маленьких сообщениях, и помедленнее на больших. Так что сейчас в процессе оптимизации работы системы. В дальнейшем планируем провести более полное сравнение и выложить результаты.

Надо больше цифр. Пропускная способность, размеры сообщений, количество сообщений, задержки, требуемое железо.

Цифры есть здесь: https://mcs.mail.ru/cloud-queues/

С точки зрения пользователя предоставляется облачный сервис и можно не думать о требованиях к железу.

Спасибо. Жалко что только облако. Но в общем понятно почему так.

Планируем сделать on-premise реализацию, можно будет разворачивать в закрытом контуре. Как только будет готово - сформируем требования к железу исходя из требований к нагрузке и опубликуем.

А пробовал кто-то MCS SQS с Celery подружить? Есть опыт использования?

MCS SQS обладает полностью таким же API, как и Amazon SQS. Так что проблем быть не должно. Просто задать токены и урл - должно быть достаточно. Но если вы попробуете и у вас будут какие-то проблемы, то наша поддержка очень быстро отвечает.

Не планируете ли в опенсурс? Область достаточно горячая, конкурентов много и набрать коммьюнити будет тяжело кмк, если будет только в вашем облаке и он-премис.

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

А можно немного подробнее про long polling: в случае множества параллельных запросов как определяется кому какие сообщения отдавать? Допустим мы ожидаем для первого сообщения пока наберется нужное количество. Что в этот момент делают остальные запросы?

Запросы линеаризуются на текущем активном storage. Т.е. каждый новый запрос становится в очередь запросов и ожидает пока предыдущий отработает.

Sign up to leave a comment.