Descubre cómo ajustar tus servicios SOAP para que sean eficientes para solicitudes de carga masiva
Todos sabemos que cuando estamos implementando una API, necesitamos diseñar cuidadosamente el tamaño que podemos manejar como el máximo tamaño de solicitud. Por ejemplo, deberías saber que para una solicitud en línea, el límite superior habitual es de 1 MB, todo lo que supere eso deberíamos poder manejarlo de manera diferente (las opciones para manejarlo pueden ser dividir las solicitudes o usar otros protocolos en lugar de HTTP para manejar este tipo de cargas). Pero luego la vida real viene a enfrentarnos allí.
No siempre es posible ceñirse al plan. No siempre somos nosotros los que tomamos esa decisión. Y podemos argumentar todo lo que queramos que esto no es una buena idea y eso está bien, pero al mismo tiempo, necesitamos hacer algo que funcione.
Por defecto, cuando estamos exponiendo un Servicio SOAP en TIBCO BusinessWorks, se basa en bibliotecas de terceros para gestionar la solicitud, analizarla y ayudarnos a acceder al contenido de las solicitudes. Algunas de ellas provienen de la Fundación Apache, y de la que vamos a hablar es Apache Commons.
Cuando estamos enviando una solicitud grande a nuestro servicio SOAP, en mi caso, esta es una solicitud SOAP de 11 MB a mi sistema, y empiezo a ver el siguiente comportamiento:
- El servicio no está respondiendo a mi consumidor.
- Puedo ver un uso significativo del hilo del Conector HTTP manejando la solicitud antes de enviarla al servicio real.
- La CPU y la memoria están aumentando mucho.
Entonces, ¿cómo podemos mejorar eso? Lo primero es profundizar más en los detalles sobre ese uso extensivo de la CPU. Por ejemplo, si vamos al seguimiento de pila que los hilos del Conector HTTP están ejecutando, puedes ver el siguiente seguimiento de pila:
Puedes obtener esa información de varias fuentes:
- Una es usar el JVisual VM e ir a los detalles del snapshot en las muestras como lo hice yo.
- También puedes obtener un volcado de hilos y usar herramientas como https://fastthread.io/index.jsp para visualizarlo gráficamente.
Aquí podemos ver que estamos atascados en el método de registro. Y eso es extraño, ¿por qué estoy registrando estas solicitudes si no estoy haciendo eso en la configuración de BusinessWorks? La respuesta es bastante simple: las bibliotecas de Apache tienen su propio sistema de registro que no se ve afectado por la configuración de logback que usa BusinessWorks.
Entonces, podemos desactivar eso usando la siguiente propiedad JVM:
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog
El tiempo de respuesta ha mejorado de 120 segundos para 11 MB a menos de 3 segundos, incluyendo toda la lógica que el servicio estaba haciendo. Bastante impresionante, ¿verdad?
Resumen
Espero que encuentres esto interesante, y si eres uno de los que enfrenta este problema ahora, tienes información para no detenerte por este. Si deseas enviar tus preguntas, no dudes en usar una de las siguientes opciones:
- Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usando el hashtag #TIBFAQS que monitorearé.
- Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
- Instagram: Puedes enviarme un DM en Instagram a @alexandrev
