español - rabbitmq java example code
RabbitMQ en los desafíos de rendimiento EC2 (3)
¿Cuáles podrían ser las expectativas de rendimiento de RabbitMQ en EC2? Agradeceríamos compartir la experiencia aquí.
Estoy intentando hacer una prueba de rendimiento de RabbitMQ en aws EC2. Tengo 3 instancias independientes de EC2 ejecutándose para RabbitMQ, Publisher y consumer / worker.
El escenario que tengo es que Publisher empuja la cadena JSON (aproximadamente 165-200 bytes) al tipo de intercambio directo con el conjunto duradero a verdadero y enlaza la cola con el conjunto duradero a verdadero (es decir, ambos en modo persistente). El consumidor / trabajador se está ejecutando en una caja separada, sigue sacando mensajes. (Se espera que estos mensajes en el trabajador se mantengan en MongoDB y Publisher será reemplazado por Restful service usando REST fácil)
Para mantener las cosas simples, simulé este escenario utilizando el código de muestra de multidifusión. Había dividido el código de multidifusión en dos archivos java separados, a saber, "Productor" y "Trabajador" para ejecutar cada uno en un cuadro separado. He usado "c1.mediam" EC2 con el servidor Ubuntu v11.4 de 32 bits para ejecutar el productor y el consumidor y "m1.large" con el servidor de Ubuntu v11.4 de 64 bits para RabbitMQ.
Puedo lograr un rendimiento de 3-5k mensajes por segundo, es decir, mantener la tasa de inserción del mensaje de estudio en 5K. (Esto coincide con http://www.rabbitmq.com/faq.html#performance-latency )
Además, cuando aumento la velocidad de inserción a 10-12k mensajes por segundo. La capacidad del consumidor para consumir mensajes cae a 1-2k mensajes por segundo y genera un retraso acumulado (Muchas veces va por debajo de 800 mensajes por segundo también).
Con el escenario anterior, tengo las siguientes preguntas y agradecería pensamientos / sugerencias para mejorar el rendimiento del consumidor también. (NOTA: se espera que todos los mensajes de mi escenario tengan un tipo similar que no brinde la oportunidad de agruparlos para establecer el enrutamiento; por lo tanto, es posible que necesiten algún tipo de enfoque de equilibrador de carga)
1) Este rendimiento se observa con un servidor de rabbitMQ, un intercambio y una cola. Se puede configurar algo más, ajustado para improvisar un rendimiento de más de 5k con modo persistente.
2) Entiendo, la agrupación podría ser otra opción. Sin embargo, necesito configurar el clúster en función de la carga entrante y es posible que no obtenga la agrupación / identidad del mensaje para definir el enrutamiento (ya que se espera que los mensajes sean solo una descripción del registro). ¿Puedo agrupar siguiendo la opción de equilibrio de carga para trabajador / consumidor?
3) Se espera que procese varios cientos de miles de solicitudes por segundo. Agradecería compartir alguna experiencia y enfoque para lograr esto.
¿Has considerado agregar múltiples consumidores? Este es uno de los beneficios principales de una arquitectura de bus / mensaje ligeramente acoplada en comparación con una arquitectura estrictamente acoplada. También puede ser útil comprender la necesidad del volumen del mensaje. ¿Es este un punto de referencia solo para ver qué puede hacer o está vinculado a una necesidad real de la aplicación?
¿Qué tipo de almacenamiento está utilizando para las instancias de EC2? El almacenamiento de EBS es más confiable, pero a veces tiene un rendimiento muy bajo (especialmente si se trata de un volumen de EBS de pequeño tamaño, es decir, <100 GB). Instance Store, por otro lado, tiene un rendimiento mucho mejor de IO (según nuestra experiencia, al menos), pero solo puede "vivir" mientras la instancia se esté ejecutando. Además, una gran diferencia es el tipo de instancia que estás usando. m1.small y c1.medium tienen un rendimiento moderado de IO (http://aws.amazon.com/ec2/instance-types/).
Estamos ejecutando RabbitMQ en EC2 con persistencia para todos los mensajes. Usamos solo instancias m1.large (64 bits con alto rendimiento IO). Comenzamos con el almacenamiento EBS, luego cambiamos a instancia-tienda, para ver si hay alguna mejora. Y las instancias de tienda de instancias son más rápidas en términos de rendimiento IO. Pero, el inconveniente es que todos los mensajes persistentes se pierden junto con la terminación / falla de la instancia (aunque nunca hemos experimentado un error, hasta ahora). En nuestro caso, no necesitamos un rendimiento tan grande, pero sí nos importa mucho si nuestros mensajes se pierden :-)
En conclusión, podría intentar cambiar a una instalación de tienda de instancias para ver cómo funciona, si hay alguna mejora. Y si eso funciona mucho mejor, entonces creo que http://www.rabbitmq.com/pacemaker.html es una solución para superar el fracaso. Al menos esa es la dirección a la que nos estamos dirigiendo.
Aclamaciones
Cientos de kHz es muy, muy alto: si RabbitMQ puede hacer eso, estás buscando particionar en nodos agrupados. Estos escritores encontraron que sus instancias EC2 podían procesar a lo sumo 100K paquetes / segundo, por lo que obviamente no obtendrás un rendimiento de mensajes más alto que eso a través de una única instancia.
Puede investigar Kafka , escrito por LinkedIn para un tipo similar de modelo de gran firehose. Impulsa cierta complejidad a los consumidores para permitir una distribución genuina y una sobrecarga de mensajes más baja.