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

Discover how to fine-tune your SOAP services to be able to be efficient for massive payload requests

We all know that when we are implementing API, we need to carefully design the size that we can manage as the maximum of request size. So, for example, you should know that for an online request, the usual upper limit is 1 MB, everything beyond that we should be able to manage it differently (options to drive can be slicing the requests or using other protocols rather than HTTP to handle this kind of loads). But then real-life comes to tackle us there.

Not always this is possible to stick to the plan. Not always we are the ones making that decision. And we can argue as long as we like that this is not a good idea and that is great, but at the same time, we need to do something that is working.

By default, when we are exposing a SOAP Service on TIBCO BusinessWorks, it relies on third-party libraries to manage the request, parse it, and help us access the requests’ content. Some of them come from the Apache Foundation, and the one that we are going to talk about is Apache Commons.

When we are sending a big request to our SOAP service, in my case, this is an 11 MB SOAP request to my system, and I start to see the following behavior:

• Service is not responding to my consumer.
• I can see significant usage of the HTTP Connector thread handling the request before sending it to the actual service.
• CPU and memory are increasing a lot.

So, how can we improve that? The first thing is to go more into the details about that extensive CPU usage. For example, if we go into the stack trace that the HTTP Connector threads are running, you can see the following stack trace:

You can get that information from several sources:

• One is using the JVisual VM and going to the snapshot details in the samples as I did.
• You can also get a thread dump and use tools such as https://fastthread.io/index.jsp to visualize it graphically.

Here we can see that we’re stuck at the log method. And that is strange why I am logging these requests if I’m not doing that in the BusinessWorks configuration. The answer is quite simple: Apache libraries have their logging system that is not affected by the logback configuration BusinessWorks uses.

So, we can disable that using the following JVM property:

-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog

Response time has improved from 120 seconds for 11 MB to less than 3 seconds, including all the logic the service was doing. Pretty impressive, right?

Summary

I hope you find this interesting, and if you are one of those facing this issue now, you have information not to be stopped by this one. If you would like to submit your questions feel free to use one of the following options:

• Twitter: You can send me a mention at @alexandrev on Twitter or a DM or even just using the hashtag #TIBFAQS that I will monitor.
• Email: You can email me to alexandre.vazquez at gmail.com with your question.
• Instagram: You can send me a DM on Instagram at @alexandrev