Hi
I'm trying to understand a little about the relationship between Service Type Instances and how messages are processed, with a view to message throughput performance.
The Container implements a finite number of Service Type Instances, both the standard ones provided by Sonic and our own Java Service Types. ESB Process Steps refer to these Service Type Instances to perform Message processing.
What happens when multiple ESB Processes which are processing separate messages at the same time refer to the same Service Type Instance?
If an ESB Process is executing a Step, that is a particular Service Type Instances, do other ESB Process wanting to use that Instance have to wait until the first Process finishes with it?
If that is so, can you provide some advice on how to avoid perfformance bottlenecks in this situation?
If not, can you give me some insight into why not?
Is there some reading I should refer to?
We are processing primarily through Sonic Connect (8.5) Web Services so it is possible to be processing many messages simultaneously.
Thanks
Steve
Hello Stephen,
Here is what I know about that. You shouldn't have any bottleneck with an ESB service type if you set an appropriate number of listeners and use a topic with Shared Subscriptions(a queue would work too) on your service EndPoint. The number of listeners for a service is limited to the resources of the host machine and the maximum memory for a single process. You can gain more throuhput by deploying service instances on multiple machines.
So, if you set multiple listeners on your service type, multiple processes running simultaneously will not have to wait unless all service instances are busy. In that case you can increase the number of listeners for your service type.
I hope this helps.
Regards,
Jimmy
Thanks Jimmy
That was quite helpful.
So that means we specify more than one listener on a Service Type Instance Entry Endpoint in a Container.
Out of curiosity, is the way that is implemented to fire off the service() method in a new thread for each listener?
If we wanted to measure any contention for calls to Service Type Instances then we'd need to know how long a message spent waiting at the entry endpoint? Do you know if there is a way to measure that?
That being asked, I understand the point about keeping the balance between message processing and available machine resources.
Regards
Steve
"Out of curiosity, is the way that is implemented to fire off the service() method in a new thread for each listener?"
Yes it seems to be the way it works. Each listener corresponds to a thread and the service() method is fired off for each message that arrives in the "InBox" of the service.
For monitoring, I think it will be difficult if you're using a Topic. But if you're using a Queue as the service entry point, you could probably use the one or more of the queue metrics to do it. You can activate them by right-clicking on the broker, then Metrics.
Regards,
Stephen, SonicGuys,
Have you seen cases where a library or layer of code that is written to be executed within a SonicESB Custom Service processes much slower in the SonicESB Custom Service than in standalone testing of the library/layer outside of Sonic?
I'm leveraging a library that takes the XML from incoming messages, makes calls to a service layer passing in this XML, and generally the lower level layer performs some database operation. Within the service() method of the Sonic Custom Service, the execution of this underlying library/layer takes anywhere from 3, 4, or 5 times as long.
To benchmark, I ran an eclipse based JUnit test with these VM Arguments:
-XX:MaxPermSize=128m -Xms512m -Xmx512m
I have these VM arguments on my MF Container which contains my ESB custom services making the same executions:
-Xms1024m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=128m
If doesn't appear to be a memory problem looking at machine performance. Any ideas why execution of the same library/layer would take longer from within the SonicESB Custom Service service() method?
Thanks in advance.
Hi Chris
Sorry, I missed this one. I'm really glad you raised it. I believe we've observed that too although we haven't actually benchmarked it.
Our initial development used quite a number of Custom Service types. Peformance was absolutely hopeless and we had to go back to the drawing board.
One of our developers started working with only Sonic Native Services and was getting much better performance results but I didn't make a concrete connection between performance of Native and Custom Servie Types at the time.
The cost of that approach was:
- A lot more complex process code.
- A lot of repeated code.
- loss of function
- The prospect of really big and complex CBRs
- The prospect of escalating process steps resulting in degrading performance.
and we abandoned that too.
We settled on an approach that works well enough, but is still slower than our custom built ESB that we're replacing. It your observation about Custome Services being slower to launch can be resolved we'd be right on the money.
Regards
Steve