Better strategic. Business process with pool size = 4 or 4 business process


I want to process more requests per second in Ensemble 2015 (soap service). My problem is in a business process that makes a great transformation. I thought that I can put its group size to 4 (the current value is 1), or put 4 business processes and apply, for example, the round-robin algorithm.
Which alternative is better?


Pool size 4 would be better.

Adding 4 same processes would only make production configuration more complicated.

If performance is your concern, then avoid handing off work to additional Processes or Operations and do all the work within the Business Service, or better yet, outside of Ensemble (see: %SOAP.WebService) . Invoking synchronous requests to Business Processes/Operations is costly when dealing with high volume concurrent traffic. 

the communication between Business Service and my Business Processes is asynchronous. All the logic is in the Business Processes because, thus, the response to the origin is faster and independent of processing.


How many requests are you hoping to process? 10 per second? 100 per second? 1,000 per second? More?

The full answer to this question depends on how far you are trying to push the system.

Between 12 a.m. At 15 a.m., my business services can receive about 20 requests per second with an average size of 120KB per message. The problem is not that my business services can not get that volume, the problem is that my business process (which applies a great transformation) is my bottleneck. I have registered cases in which we have reached 9500 queues in the BP and delays of several hours.


If you don't have problems with loosing the order of messages, just increase you pool size. But you should take a look at your transformation, why is it so heavy? A transformation should not slow down your system like this.

On the other hand, if you do care about the order of messages, you could use a message router to split the channel for more processes based on some criteria that won't affect the order of messages. For instance, at a client I was receiving an HL7 feed from single system that  was used on many facilities. On this feed I had messages to create a patient, update it, admit it, etc. If one messages arrived on its destination before the previous related ones, I would loose updates. The process that was transforming them was a bottleneck (and improve it to eliminate the bottleneck would take time). So we ended up creating a routing rule to split the HL7 feed by facility and created an instance of that business process for each facility. That allowed us to parallelize the processing while still keeping the order of messages (because I patient couldn't be on more than one facility at the same time).

Of course, we later took the time to improve that business process that was slow an retrofitted the production back to fast simplicity. ;)

Kind regards,


In which case, please mark one of the Answers as "accepted". This helps the Developer Community spot questions that haven't yet been answered to the satisfaction of the OP.