queue - nack - rabbitmq no ack
¿Hay una diferencia de rendimiento entre agrupar conexiones o canales en rabbitmq? (3)
Soy un novato con Rabbitmq (y programación), lo siento de antemano si esto es obvio. Estoy creando un grupo para compartir entre los subprocesos que están trabajando en una cola, pero no estoy seguro de si debo usar conexiones o canales en el grupo.
Sé que necesito canales para hacer el trabajo real, pero ¿hay un beneficio en el rendimiento de tener un canal por conexión (en términos de mayor rendimiento de la cola)? ¿O estoy mejor usando una sola conexión por aplicación y agrupando muchos canales?
nota: como estoy agrupando los recursos, el costo inicial no es un factor, ya que sé que las conexiones son más caras que los canales. Estoy más interesado en el rendimiento.
Además de la respuesta aceptada:
Si tiene un grupo de nodos RabbitMQ con un equilibrador de carga al frente o un DNS de corta duración (lo que hace posible conectarse a un nodo de conejo diferente cada vez), entonces una única conexión de larga duración significaría que uno El nodo de aplicación funciona exclusivamente con un solo nodo RabbitMQ. Esto puede hacer que un nodo RabbitMQ sea más utilizado que los otros.
La otra preocupación mencionada anteriormente es que la publicación y el consumo están bloqueando las operaciones, lo que lleva a la cola de mensajes. Tener más conexiones asegurará que 1. el tiempo de procesamiento de cada mensaje no bloquee otros mensajes 2. los mensajes grandes no están bloqueando otros mensajes.
Es por eso que vale la pena considerar la posibilidad de tener un pequeño grupo de conexiones (teniendo en cuenta los problemas de recursos mencionados anteriormente)
El "un canal por hilo" puede ser una suposición segura (digo que podría, ya que no he realizado ninguna investigación por mi cuenta y no tengo ninguna razón para dudar de la documentación :)) pero tenga en cuenta que hay un caso en el que esto se rompe:
Si utiliza RPC con la respuesta directa de RabbitMQ, no podrá reutilizar el mismo canal para consumir para otra solicitud de RPC. Pedí detalles sobre eso en el grupo de usuarios de Google y la respuesta que recibí de Michael Klishin (que parece estar activamente involucrado en el desarrollo de RabbitMQ) fue que
La respuesta directa a no está destinada a ser utilizada con el intercambio de canales de ninguna manera.
He enviado un correo electrónico a Pivotal para actualizar su documentación para explicar cómo amq.rabbitmq.reply-to está funcionando bajo el capó y todavía estoy esperando una respuesta (o una actualización).
Así que si quiere mantener "un canal por hilo", tenga cuidado, ya que esto no funcionará bien con la respuesta directa.
Encontré esto en el sitio web de rabbitmq , está cerca del final, por lo que he citado la parte correspondiente a continuación.
La versión tl; dr es que debes tener 1 conexión por aplicación y 1 canal por hilo. Espero que ayude.
Conexiones
Las conexiones AMQP suelen ser de larga duración. AMQP es un protocolo de nivel de aplicación que usa TCP para una entrega confiable. Las conexiones AMQP utilizan autenticación y pueden protegerse mediante TLS (SSL). Cuando una aplicación ya no necesita estar conectada a un agente AMQP, debe cerrar la conexión AMQP con gracia en lugar de cerrar abruptamente la conexión TCP subyacente.
Los canales
Algunas aplicaciones necesitan múltiples conexiones a un agente AMQP. Sin embargo, es indeseable mantener muchas conexiones TCP abiertas al mismo tiempo, ya que al hacerlo consume recursos del sistema y hace que sea más difícil configurar los firewalls. Las conexiones AMQP 0-9-1 se multiplexan con canales que se pueden considerar como "conexiones ligeras que comparten una sola conexión TCP".
Para las aplicaciones que utilizan varios subprocesos / procesos para el procesamiento, es muy común abrir un nuevo canal por subproceso / proceso y no compartir canales entre ellos.
La comunicación en un canal en particular es completamente independiente de la comunicación en otro canal, por lo tanto, cada método AMQP también lleva un número de canal que los clientes usan para determinar para qué canal es el método (y por lo tanto, qué controlador de eventos debe invocarse, por ejemplo) .
Se recomienda que haya 1 canal por subproceso, aunque son seguros para subprocesos, por lo que podría tener múltiples subprocesos a través de un canal. Sin embargo, en términos de su aplicación, sugeriría que se quede con 1 canal por hilo.
Adicionalmente se aconseja tener solo 1 consumidor por canal.
Estas son solo pautas, por lo que tendrá que hacer algunas pruebas para ver qué funciona mejor para usted.
Este hilo tiene algunas ideas here y here .
A pesar de todas estas pautas, esta publicación sugiere que probablemente no afectará el rendimiento al tener múltiples conexiones. Aunque no es específico si se trata del lado del cliente o del lado del servidor (rabbitmq). Con el único punto de que, por supuesto, utilizará más recursos de sistemas con más conexiones. Si esto no es un problema y desea tener más rendimiento, puede ser mejor tener múltiples conexiones ya que esta publicación sugiere que múltiples conexiones le permitirán un mayor rendimiento. La razón parece ser que incluso si hay varios canales, solo un mensaje pasa a través de la conexión a la vez. Por lo tanto, un mensaje grande bloqueará toda la conexión o muchos mensajes sin importancia en un canal pueden bloquear un mensaje importante en la misma conexión pero en un canal diferente. Nuevamente los recursos son un problema. Si está utilizando todo el ancho de banda con una conexión, al agregar una conexión adicional no aumentará el rendimiento en comparación con tener dos canales en una conexión. Además, cada conexión utilizará más memoria, CPU y archivos, pero eso puede no ser una preocupación, aunque puede ser un problema al escalar.