ZeroMQ, RabbitMQ 및 Apache Qpid의 성능 비교


78

애플리케이션에 고성능 메시지 버스가 필요하므로 ZeroMQ, RabbitMQ및의 성능을 평가 하고 Apache Qpid있습니다. 성능을 측정하기 위해 메시지 큐 구현 중 하나를 사용하여 10,000 개의 메시지를 게시하고 동일한 시스템에서 다른 프로세스를 실행하여 10,000 개의 메시지를 소비하는 테스트 프로그램을 실행하고 있습니다. 그런 다음 첫 번째 게시 된 메시지와 마지막으로받은 메시지 사이의 시차를 기록합니다.

다음은 비교에 사용한 설정입니다.

  1. RabbitMQ: 기본 구성으로 "팬 아웃"유형 교환 및 대기열을 사용했습니다. RabbitMQ C 클라이언트 라이브러리를 사용했습니다.
  2. ZeroMQ: 내 게시자 tcp://localhost:port1ZMQ_PUSH소켓 을 사용 하여 게시 하고 , 내 브로커 tcp://localhost:port1는 메시지를 수신하고 tcp : // localhost : port2로 다시 전송하고 내 소비자는 소켓 을 tcp://localhost:port2사용하여 수신 ZMQ_PULL합니다. 나는 브로커를 사용하는 ZeroMQ다른 메시지 큐 구현과 성능 비교를 공정하게 만들기 위해 피어 투 피어 통신 대신 브로커를 사용하고 있습니다.
  3. QpidC ++ 메시지 브로커 : "팬 아웃"유형 교환과 기본 구성의 대기열을 사용했습니다. Qpid C ++ 클라이언트 라이브러리를 사용했습니다.

다음은 성능 결과입니다.

  1. RabbitMQ: 10,000 개의 메시지를 수신하는 데 약 1 초가 걸립니다.
  2. ZeroMQ: 10,000 개의 메시지를 수신하는 데 약 15 밀리 초가 걸립니다.
  3. Qpid: 10,000 개의 메시지를 수신하는 데 약 4 초가 걸립니다.

질문 :

  1. 메시지 대기열간에 유사한 성능 비교를 실행 한 사람이 있습니까? 그런 다음 내 결과를 귀하의 결과와 비교하고 싶습니다.
  2. 튜닝 RabbitMQ하거나 Qpid성능을 향상 시킬 수있는 방법이 있습니까?

노트 :

테스트는 두 개의 프로세서가 할당 된 가상 머신에서 수행되었습니다. 결과는 하드웨어마다 다를 수 있지만 주로 MQ 제품의 상대적 성능에 관심이 있습니다.


3
몇 달 전에 비슷한 결과로 간단한 테스트를 실행했습니다. 그리고 RabbitMQ 또는 Qpid로 작업 할 때 시스템이 매우 유휴 상태임을 알았습니다. 뭔가 잘못된 것 같아요.
Gary Shi

"RabbitMQ : 10,000 개의 메시지를 수신하는 데 약 12 ​​초가 걸립니다." -자체 테스트에서 CPU 당 20-25,000 / 초의 수신을 정기적으로 확인합니다. 그래서, 당신은 뭔가 잘못하고 있거나 느린 클라이언트를 사용하고 있습니다. 질문이있는 rabbitmq-discuss를 이메일로 보냈습니까?

1
다음은 2013 년 4 월 10 일자 좋은 비교입니다. x-aeon.com/wp/2013/04/10/…
Daniel F

3
RabbitMQ, Kafka, HornetQ, ActiveMQ, SQS 및 Mongo 성능 비교의 업데이트 된 버전이 지금 여기에 있습니다. softwaremill.com/mqperf
adamw

2
이 테스트를 수행했을 때 각 메시지는 몇 바이트였습니까?
arsenal

답변:


104

RabbitMQ는 아마도 해당 메시지에 대해 지속성을 수행하고 있습니다. 지속성을하지 않으려면 메시지 우선 순위 또는 다른 옵션을 메시지에 설정해야한다고 생각합니다. 그러면 성능이 10 배 향상됩니다. AMQP 브로커를 통해 초당 최소 100,000 개의 메시지를 예상해야합니다. OpenAMQ에서는 초당 최대 300K 메시지의 성능을 얻었습니다.

AMQP 속도를 위해 설계되었지만 (예 : 메시지를 라우팅하기 위해 메시지를 압축 해제하지 않음) ZeroMQ는 단순히 주요 방식으로 더 잘 설계되었습니다. 예를 들어 브로커없이 노드를 연결하여 홉을 제거합니다. AMQP 클라이언트 스택보다 더 나은 비동기 I / O를 수행합니다. 보다 적극적인 메시지 일괄 처리를 수행합니다. ZeroMQ를 구축하는 데 소요 된 시간의 60 %가 성능 튜닝에 사용되었습니다. 매우 힘든 일이었습니다. 우연히 빠르지는 않습니다.

한 가지하고 싶지만 너무 바쁘다는 것은 ZeroMQ 위에 AMQP와 같은 브로커를 다시 만드는 것입니다. 여기에 첫 번째 레이어가 있습니다 : http://rfc.zeromq.org/spec:15 . 전체 스택은 전송 및 의미 체계가 두 계층으로 분리되어 RestMS와 비슷하게 작동합니다. AMQP / 0.9.1 (및 의미 상 상호 운용 가능)과 거의 동일한 기능을 제공하지만 훨씬 더 빠릅니다.


누군가 @pieter btw보다 나은 해결책을 찾을 때까지 rabbitmq를 계속 사용할 것입니다. 훌륭한 특허 이야기 [1]를 상기시킵니다. [1] youtube.com/watch?v=5QqbDyZ8Eu4
Kunthar

57
RIP 동료, 당신은 훌륭한 물건 내장
길레스피

33

흠, 물론 ZeroMQ는 더 빠를 것이며, 다른 두 개가 제공하는 많은 브로커 기반 기능을 갖도록 설계되었으며 포함하지 않습니다. ZeroMQ 사이트 brokerless 메시징과 단점 및 모두의 장점 대 브로커의 멋진 비교가 있습니다.

RabbitMQ 블로그 :

RabbitMQ와 0MQ는 메시징의 다양한 측면에 초점을 맞추고 있습니다. 0MQ는 메시지가 유선을 통해 전송되는 방식에 훨씬 더 중점을 둡니다. 반면 RabbitMQ는 메시지를 저장, 필터링 및 모니터링하는 방법에 중점을 둡니다.

(또한 RabbitMQ와 함께 ZeroMQ를 사용하는 것에 대해 이야기하기 때문에 위의 RabbitMQ 게시물도 마음에 듭니다)

그래서 제가 말하고자하는 것은 여러분의 요구 사항에 가장 잘 맞는 기술을 결정해야한다는 것입니다. 유일한 요구 사항이 속도 인 경우 ZeroMQ. 그러나 메시지 지속성, 필터링, 모니터링, 장애 조치 등과 같은 다른 측면이 필요한 경우 RabbitMQ 및 Qpid를 고려해야합니다.


4
ZeroMQ에는 브로커가 없습니다. 브로커를 애플리케이션의 전체 디자인의 일부로 설계하고 브로커는 zeromq에서 수신하여 대상에 맞게 메시지를 라우팅합니다. ZeroMQ는 단 하나의 작업을 수행하며 매우 잘 수행합니다. 바로 메시지 큐잉입니다. ØMQ 사람들이 ØMQ를 위해 디자인 한 브로커 구현 인 Malamute가 있지만 ØMQ의 일부는 아닙니다. ØMQ와 함께 자체 프로세스 또는 메시지 중개 전용 박스에 설치할 수있는 서비스입니다. 그것은 자체 프로젝트입니다. github.com/zeromq/malamute
닐 데이비스

예, 브로커가 없으며 브로커 대 브로커리스의 기사에 링크되어 있다고 말했습니다. 명확하지 않습니까? 나는 2011 년에이 답변을 게시하는 경우 또한 10 월 2014 년 등장에는 에스키모, 없었다
스티브 케이시

4

브로커를 사용하는 다른 메시지 큐 구현과 성능 비교를 공정하게 만들기 위해 ZeroMQ에서 피어 투 피어 통신 대신 브로커를 사용하고 있습니다.

왜 그렇게하고 싶은지 잘 모르겠습니다. 당신이 관심을 갖는 유일한 것이 성능이라면, 경기장 수준을 만들 필요가 없습니다. 지속성, 필터링 등에 대해 관심이 없다면 왜 대가를 지불해야합니까?

또한 VM에서 벤치 마크를 실행하는 데 매우 신경이 쓰입니다. 명확하지 않은 방식으로 결과에 영향을 미칠 수있는 추가 레이어가 많이 있습니다. (물론 VM에서 실제 시스템을 실행할 계획이 아니라면 이는 매우 유효한 방법입니다).


3

C ++ / qpid를 테스트했습니다.

대기열에 넣지 않고 오랫동안 서로 다른 두 시스템간에 초당 50000 개의 메시지를 보냈습니다.

팬 아웃을 사용하지 않고 단순한 교환 (비 지속 메시지)

지속적 메시지를 사용하고 있습니까? 메시지를 구문 분석하고 있습니까?

0MQ에는 메시지 구조체가 없기 때문에 그렇지 않은 것 같습니다.

브로커가 주로 유휴 상태 인 경우 보낸 사람과받는 사람에 대한 프리 페치를 구성하지 않았을 수 있습니다. 이것은 많은 메시지를 보내는 데 매우 중요합니다.


비 영구 대기열을 사용하고 있으며 메시지를 구문 분석하지 않습니다. 실제로 세 가지 대기열 실험 모두에 대해 메시지를 생성하는 데 동일한 코드를 사용하고 있습니다. 교환 유형을 직접으로 변경해도 성능에 영향을 미치지 않았습니다. 또한 발신자 흐름 제어 (api sender.SetCapaclity (8))를 사용한 후 타이밍이 나빠졌습니다. 발신자 흐름 제어가 없으면 대기열이 제한없이 증가하는 것처럼 보입니다. 시간을 측정 할 때 모든 메시지를 수신하고 대기열이 완전히 비워 질 때까지 기다렸습니까?
ahsankhan

1
나는 qpid-perftest 프로그램이 Qpid의 "오래된 메시징 Apis"를 사용하고 있음을 발견했습니다. 이전 Apis로 전환하면 테스트에서 성능이 10 배 향상되었습니다.
ahsankhan

1

우리는 RabbitMQ 를 모든 소스 코드와 함께 http://www.udaparts.com/document/articles/fastsocketpro.htm 사이트 의 SocketPro ( http://www.udaparts.com/ ) 영구 메시지 대기열 과 비교했습니다 . RabbitMQ에 대해 얻은 결과는 다음과 같습니다.

동일한 시스템 대기열에 넣기 및 대기열에서 빼기 :

"Hello world"-
대기열에 넣기 : 초당 30000 개의 메시지;
대기열에서 빼기 : 초당 7000 개의 메시지.

1024 바이트 텍스트-
대기열에 넣기 : 초당 11000 개의 메시지
대기열에서 빼기 : 초당 7000 개의 메시지.

10 * 1024 바이트 텍스트-
대기열에 넣기 : 초당 4000 개의 메시지
대기열에서 빼기 : 초당 4000 개의 메시지.

네트워크 대역폭 100mbps로 시스템 간 대기열에 추가 및 대기열에서 빼기 :

"Hello world"-
대기열에 넣기 : 초당 28,000 개의 메시지;
대기열에서 빼기 : 초당 1900 개의 메시지.

1024 바이트 텍스트-
대기열에 넣기 : 초당 8000 개의 메시지
대기열에서 빼기 : 초당 1000 개의 메시지.

10 * 1024 바이트의 텍스트-
대기열에 넣기 : 초당 800 개 메시지;
대기열에서 빼기 : 초당 700 개의 메시지.


0

발신자 및 수신자에 대해 100과 같은 값으로 프리 페치를 구성 해보십시오. 발신자 만 프리 페치하는 것으로는 충분하지 않습니다.


qpid의 경우 Receiver.setCapacity (100)가 수신자에 대한 프리 페치를 설정한다는 인상을 받았습니다. 그렇게하면 "new qpid api"를 사용하는 코드의 성능이 10 배 향상되었으며 Qpid 이전 메시징 API와 유사한 성능이 향상되었습니다. 결과로 게시물을 업데이트했습니다. 그러나 Qpid는 여전히 rabbitmq보다 4 배 느린 것 같습니다.
ahsankhan

0

우리는 ZeroMQ 위에 구축 된 오픈 소스 메시지 버스를 개발했습니다. 처음에는 Qpid를 대체하기 위해 이렇게했습니다. 중개인이 없으므로 완전히 공정한 비교는 아니지만 중개 솔루션과 동일한 기능을 제공합니다.

헤드 라인 성능 수치는 두 컴퓨터 사이의 초당 140K 메시지이지만 여기에서 자세한 내용을 볼 수 있습니다. https://github.com/Abc-Arbitrage/Zebus/wiki/Performance

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.