none
WebServices de Consumo masivo RRS feed

  • Debate general

  • Buenas tardes,

       En la empresa que trabajo, actualmente tenemos una aplicación de monitoreo creada en Java, para no sobrecargar esta aplicación queremos implementar un WS en .NET (idealmente C#) a la cual se comunique y le entregue un mensaje, la idea es que este WS almacene este mensaje en una bae de datos, el problema es que es de alto consumo, en momentos de pick puede llegar a las 1300 transacciones por minuto.

       El problema es saber como aseguramos que el WS podrá procesar la carga de este proceso, sin caída y como podemos hacerlo mas optimo para tampoco saturar la base de datos (SQL Server 2008), estimados, pueden darme alguna opinión o link donde pueda leer mas al respecto y poder implementar una solución robusta y efectiva que no me de dolores de cabeza.

       De antemano muchas gracias :)

    martes, 22 de marzo de 2016 21:25

Todas las respuestas

  • hola

    si los mensajes son tantos no uses una base de datos, o al menos de forma directa

    usa una Queue (Ms Queue o RabbitMQ) o en su defecto una db NoSql (RavenDB o MongoDb) estos son miles de veces mas rapidas que una db relacional

    Despues en un proceso batch (el cual cuenta con mas tiempo de procesamiento que el online) puedes trabajar estos mensaje con algun job o Window service tomando los datos de la Queue o la db NoSql procesarla y llevarla a la db relacional

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    martes, 22 de marzo de 2016 21:45
  • [...] puede llegar a las 1300 transacciones por minuto.


    No es mucho. Yo he llegado a hacer pruebas en las que se alcanzaban 20.000 transacciones por segundo... ¡en un laptop! (ni siquiera era un servidor potente). 1300 por minuto es una trivialidad, tanto para SQL Server como para un WS en IIS, solo son unas 22 por segundo. Ni te preocupes, podrías soportarlo incluso con un viejo PC.
    martes, 22 de marzo de 2016 22:01
  • Alberto, puede ser pero debes considerar que esas transacciones son solo de insert, tenemos al menos 3 veces eso de consulta y no debo generar perdida, ya que el escenario es el siguiente:

    7 segundos para el total de la transacción

    socket recibe mensaje y abre un hilo  (enviando acá a la base)

    socket envia mensaje a bus de servicio

    validaciones de negocios

    consultas en base de datos (si es a WS de cliente, puede tardar en promedio 4 segundos)

    respuesta hacia socket

    socket envia respuesta cliente ( deberia cargar el resultado del mensaje original)

    entonces con este escenario además de los diferentes procesos de monitoreo me hace pensar en la factibilidad de bloqueo de tabla y que no permita cerrar el ciclo en los 7 segundos de SLA comprometidos.

    de igual forma.... te agradesco tu comentario.

    sábado, 26 de marzo de 2016 1:56
  • Leandro,

      Muchas gracias por tu información voy a revisar lo que me señalas y te cuento :)

    sábado, 26 de marzo de 2016 1:58
  • No entiendo.  En su pregunta original solamente mencionó recepción de mensajes.  ¿Pero ahora también devuelve información?

    Concuerdo con Alberto que probablemente ese número es bajo.  Sin embargo no debe usted tomarnos la palabra.  Lo que usted debe hacer es realizar pruebas de estrés, aunque si ya sabe de las 1300/min supongo que ya lo tiene en operación.  En fin, volviendo a las pruebas de estrés:  Realice las pruebas midiendo los parámetros de éxito, que imagino es tiempo de respuesta y cantidad de no-respuestas (timeouts).  Si no tiene timeouts y todos los tiempos de respuesta están dentro de lo esperado, no tiene de qué preocuparse.


    Jose R. MCP
    Code Samples

    sábado, 26 de marzo de 2016 16:42