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