¿Es Amazon SQS la elección correcta aquí? Problema en el rendimiento de los rieles

Question

Estoy a punto de lanzar una aplicación de rieles con las funciones de red comunes (mensajería, pared, etc.). Quiero utilizar algún tipo de procesamiento en segundo plano (probablemente Bj) para las tareas de descarga desde el ciclo de solicitud/respuesta.

Esto sucedería cuando los usuarios inviten amigos por correo electrónico para unirse y recibir notificaciones por correo electrónico.

No estoy seguro de si debería dejar estas invitaciones y notificaciones en mi base de datos, usar un modelo y luego procesarlo con un proceso de trabajo cada x minutos o si debería ir a Amazon SQS, almacenar los mensajes y invita allí y deja que mi trabajador lo recupere de Amazon SQS para procesarlo (enviando las invitaciones/notificaciones).

El enfoque de Amazon descargaría mi base de datos, pero creo que es más lento recuperar mensajes desde allí.

¿Qué opinas?

Answer 1

Su título indica que tiene un problema de rendimiento de Rails, pero ¿lo sabe con certeza? Por el resto de su pregunta, parece que está tratando de anticipar un posible problema de rendimiento futuro. La única forma de lidiar de manera sensata con los problemas de rendimiento es llevar tu aplicación a la naturaleza y perfilarla. Si lo hace, le dará datos empíricos sobre cuáles son los problemas reales de rendimiento.

Dado que Amazon SQS no es gratuito y el hecho de que el uso es casi seguro que añadir complejidad a su aplicación, me gustaría migrar a ella si y cuando carga de la base de datos se convierte en un problema. No intentes adivinar los problemas antes de que surjan, porque es probable que te enfrentes a problemas diferentes cuando la aplicación se publique, y algunos de ellos probablemente no los hayas tenido en cuenta.

El punto principal es que ya ha decidido utilizar el procesamiento de fondo, que es la decisión correcta, dado que cualquier tipo de procesamiento que no sea instantáneo no pertenece al ciclo de solicitud/respuesta de Rails, como bloquea el proceso de Rails. Siempre puede escalar con Amazon más adelante si lo necesita.

Answer 2

Estoy de acuerdo con John Topley en que no quiere complicar demasiado su aplicación si no la necesita. Dicho esto, hay momentos en los que es bueno tomar esta clase de decisión anticipadamente, ¿anticipa una gran carga desde el principio? ¿Lo está implementando en una base de usuarios existente o es un sitio público que puede o no despegar?

Si sabe que tendrá que manejar una gran cantidad de tráfico desde el principio, entonces este podría ser un buen paso. Si no quiere gastar dinero para usar SQS, eche un vistazo a algunas de las soluciones de colas gratuitas como RabbitMQ.

Actualmente, envío un par de millones de mensajes al mes a través de SQS y funciona bastante bien. Asegúrate de planear que esté inactivo o lento de vez en cuando, por lo que necesitarías trabajar en algunas instalaciones de reintento y retroceso exponencial. Una de las cosas buenas es que puede obtener 10 mensajes a la vez que acelera la capacidad de trabajar a través de la cola, puede usar una solicitud para obtener los 10 mensajes y procesarlos 1 por 1.

Answer 3

Es su aplicación alojado en Amazon EC2 ya? Probablemente no trasladaría una aplicación existente a AWS solo para que pueda usar SQS, pero si ya está usando la infraestructura de Amazon, SQS es una gran opción. Ciertamente podría configurar su propio sistema de mensajería (como RabbitMQ), pero al ir con SQS esa es una cosa menos de la que tiene que preocuparse.

Hay muchas opciones para agregar procesamiento de fondo a las aplicaciones de Rails, como delayed_job o background_job, pero mi favorito personal es Workling. Le brinda una agradable capa de abstracción que le permite conectar diferentes corredores de fondo sin tener que cambiar la implementación real de sus trabajos.

Mantengo un Workling fork that adds an SQS client. Hay algunas deficiencias (lea los comentarios o my blog post para más detalles), pero en general funcionó bien para nosotros en mi última puesta en marcha.

También utilicé SQS para un proyecto separado de Ruby (sin rieles) y en general me pareció confiable y lo suficientemente rápido. Como señaló James anteriormente, puede leer hasta 10 mensajes a la vez, por lo que definitivamente querrá hacerlo (mi cliente Workling SQS hace esto y almacena los mensajes localmente).

Answer 4

Si tiene problemas para trasladarse a EC2, puede utilizar otros servicios como onlinemq.com.

Answer 5

Amazon SQS es un buen servicio, salvo que de las siguientes cosas se vuelven importantes:

• Rendimiento
• legales
• Agradecimientos y Transacciones
• mensajería modismos Propiedades del mensaje
• seguridad, autenticidad y Queue
• Permisos

Si alguna de estas cosas es importante, debe consultar un servicio de MQ empresarial real como StormMQ, RabbitMQ o incluso en líneamq.com.

me encontré con esta serie interesante blog ya que se compara Amazon SQS a StormMQ sin mantener ningún golpe de vuelta: http://blog.stormmq.com/2011/01/06/apples-and-oranges-performance/