rabbitmq에서 풀링 연결 또는 채널 사이에 성능 차이가 있습니까?
나는 Rabbitmq (및 프로그래밍)의 초보자이므로 이것이 분명하다면 미리 죄송합니다. 대기열에서 작업중인 스레드간에 공유 할 풀을 만들고 있지만 풀에서 연결이나 채널을 사용해야하는지 확실하지 않습니다.
실제 작업을 수행하려면 채널이 필요하다는 것을 알고 있지만 연결 당 하나의 채널을 사용하는 것이 성능상의 이점이 있습니까 (대기열에서 더 많은 처리량 측면에서)? 아니면 응용 프로그램 당 단일 연결을 사용하고 여러 채널을 풀링하는 것이 더 낫습니까?
참고 : 리소스를 풀링하고 있기 때문에 연결이 채널보다 더 비싸다는 것을 알고 있으므로 초기 비용은 요소가 아닙니다. 처리량에 더 관심이 있습니다.
나는 이것을 rabbitmq 웹 사이트 에서 발견 했고 그것이 바닥 근처에 있으므로 아래 관련 부분을 인용했습니다.
tl; dr 버전은 애플리케이션 당 1 개의 연결과 스레드 당 1 개의 채널이 있어야한다는 것입니다. 도움이되기를 바랍니다.
사이
AMQP 연결은 일반적으로 오래 지속됩니다. AMQP는 안정적인 전달을 위해 TCP를 사용하는 응용 프로그램 수준 프로토콜입니다. AMQP 연결은 인증을 사용하며 TLS (SSL)를 사용하여 보호 할 수 있습니다. 응용 프로그램이 더 이상 AMQP 브로커에 연결될 필요가 없으면 기본 TCP 연결을 갑자기 닫는 대신 AMQP 연결을 정상적으로 닫아야합니다.
채널
일부 애플리케이션은 AMQP 브로커에 대한 다중 연결이 필요합니다. 그러나 동시에 많은 TCP 연결을 열어두면 시스템 리소스가 소모되고 방화벽을 구성하기가 더 어려워지기 때문에 바람직하지 않습니다. AMQP 0-9-1 연결은 "단일 TCP 연결을 공유하는 경량 연결"로 생각할 수있는 채널로 다중화됩니다.
처리를 위해 여러 스레드 / 프로세스를 사용하는 응용 프로그램의 경우 스레드 / 프로세스별로 새 채널을 열고 채널을 공유하지 않는 것이 매우 일반적입니다.
특정 채널의 통신은 다른 채널의 통신과 완전히 분리되어 있으므로 모든 AMQP 메서드는 클라이언트가 메서드가 어떤 채널에 해당하는지 파악하는 데 사용하는 채널 번호를 전달합니다 (예를 들어 어떤 이벤트 핸들러를 호출해야하는지). .
스레드로부터 안전하더라도 스레드 당 1 개의 채널이 있으므로 하나의 채널을 통해 여러 스레드를 전송할 수 있습니다. 응용 프로그램 측면에서 스레드 당 1 개의 채널을 사용하는 것이 좋습니다.
또한 채널당 한 명의 소비자 만 사용하는 것이 좋습니다.
이것은 지침 일 뿐이므로 자신에게 가장 적합한 것이 무엇인지 확인하기 위해 몇 가지 테스트를 수행해야합니다.
이 스레드에는 여기 와 여기에 몇 가지 통찰력이 있습니다 .
이러한 모든 지침에도 불구 하고이 게시물 은 다중 연결을 통해 성능에 영향을 미치지 않을 가능성이 큽니다. 클라이언트 측인지 서버 측 (rabbitmq)인지는 구체적이지 않지만. 물론 더 많은 연결로 더 많은 시스템 리소스를 사용한다는 점이 있습니다. 이것이 문제가되지 않고 더 많은 처리량을 원한다면 이 게시물 과 같이 여러 연결을 갖는 것이 실제로 더 나을 수 있습니다.여러 연결이 더 많은 처리량을 허용 할 것임을 제안합니다. 그 이유는 여러 채널이 있어도 한 번에 하나의 메시지 만 연결을 통과하기 때문인 것 같습니다. 따라서 큰 메시지는 전체 연결을 차단하거나 한 채널의 중요하지 않은 메시지가 많은 경우 동일한 연결이지만 다른 채널에서 중요한 메시지를 차단할 수 있습니다. 다시 자원이 문제입니다. 하나의 연결로 모든 대역폭을 사용하는 경우 추가 연결을 추가해도 하나의 연결에 두 개의 채널이있는 것보다 성능이 향상되지 않습니다. 또한 각 연결은 더 많은 메모리, CPU 및 파일 핸들을 사용하지만 확장시 문제가 될 수 있지만 문제가되지 않을 수 있습니다.
허용되는 답변 외에도 :
로드 밸런서가 전면에있는 RabbitMQ 노드 클러스터 또는 수명이 짧은 DNS (매번 다른 토끼 노드에 연결할 수 있음)가있는 경우 수명이 긴 단일 연결은 하나를 의미합니다. 애플리케이션 노드는 단일 RabbitMQ 노드와 독점적으로 작동합니다. 이로 인해 하나의 RabbitMQ 노드가 다른 것보다 더 많이 활용 될 수 있습니다.
위에서 언급 한 다른 문제는 게시 및 소비가 작업을 차단하여 메시지를 대기열에 추가한다는 것입니다. 연결이 더 많으면 1. 각 메시지의 처리 시간이 다른 메시지를 차단하지 않습니다. 2. 큰 메시지가 다른 메시지를 차단하지 않습니다.
그렇기 때문에 작은 연결 풀을 고려하는 것이 좋습니다 (위에서 제기 한 리소스 문제를 염두에두고 있음).
"스레드 당 하나의 채널" 은 안전한 가정 일 수 있습니다 (내가 직접 조사를하지 않았고 문서를 의심 할 이유가 없습니다. :)) 그러나 이것이 깨지는 경우가 있음을주의하십시오.
RabbitMQ Direct reply-to 와 함께 RPC를 사용하는 경우 동일한 채널을 다시 사용하여 다른 RPC 요청에 사용할 수 없습니다 . 나는 구글 사용자 그룹 에서 그것에 대한 세부 사항을 물었고 , Michael Klishin (RabbitMQ 개발에 적극적으로 참여하는 것 같음)으로부터받은 대답은
직접 회신은 어떤 방식 으로든 채널 공유에 사용할 수 없습니다.
내부에서 어떻게 amq.rabbitmq.reply-to 작동 하는지 설명하기 위해 설명서를 업데이트하기 위해 Pivotal에 이메일을 보냈 으며 여전히 답변 (또는 업데이트)을 기다리고 있습니다.
따라서 "스레드 당 하나의 채널"을 고수하려면 직접 회신에서 제대로 작동하지 않으므로주의하십시오.
'programing tip' 카테고리의 다른 글
| 명령 줄에서 Javadoc을 생성하는 방법 (0) | 2020.12.25 |
|---|---|
| 호버시 연속 CSS 회전 애니메이션, 호버 아웃시 0deg로 다시 애니메이션 (0) | 2020.12.25 |
| 'R CMD Sweave myfile.rnw'에 해당하는 knitr는 무엇입니까? (0) | 2020.12.25 |
| Coffeescript 일치하지 않는내어 쓰기 오류 (0) | 2020.12.25 |
| md5 암호화 및 해독 (0) | 2020.12.25 |