· Feb 1

How to process parallelly a process from a business service?

Hi community.

I have an API that is deployed in my production (business service) and it calls to a business process to retrieve the information that is requested.

The problem that I have is that the calls are queued and it's creating a bottleneck 

The business process is taking more time than needed.

Is possible to configure the BP to process parallely the requests?

I'm thinking to increase the pool parameter, but I'm not sure if it's a good idea.

Best regards 

Product version: IRIS 2021.1
$ZV: IRIS for Windows (x86-64) 2021.1.3 (Build 389U) Wed Feb 15 2023 14:50:06 EST
Discussion (4)2
Log in or sign up to continue

I'm thinking to increase the pool parameter, but I'm not sure if it's a good idea.

If you are not concerned about the order of which you are processing the inbound requests, then upping the pool size to the number of parallel jobs you're looking to run with should do what you need 

However, you may need to then also apply this logic to related components that the Process interacts with, otherwise you will end up just moving the bottleneck to another component.

Alternatively, if it fits your use case, you could use the Actor Pool for your production components and then increase it to a point where you see the bottleneck drop off.

Paolo has provided the link to the documentation on Pools, which has some info on considerations for the use of the two different types of Pool.

Thanks for you answer.

We have solved the problem of the delay in BP, and now, the number of new instances of BS has been drastically reduced.

We are talking with the customer to upgrade the actor pool number to create a 3 new instances of the BP. The customer is worried that this increase in instances could affect memory performance, because more instances created, more memory it requires.

Increasing the pool value will have some effect on the RAM and CPU usage, but no different than having other jobs running through the production. If you move all the components over to using the actor pool (by setting the individual pool settings to 0) it should be easy enough to raise the value bit by bit while keeping an eye on the performance of the production and the cpu/ram usage of the machine to find a sweet spot.

If the API just needs a bit of extra resource when there's a small spike in the inbound requests, then this should not be of too much concern as it will just calm down once it's processed what has been requested.

If, however, there's a chance that it could be overloaded from inbound requests and the worry is that the server won't cope, then maybe look at using Intersystems API Manager to sit in front of the environment and make use of things like the rate limiting feature.

Or you could go even further and begin caching responses to return if the API is being queried for data that isn't changing much so that there's less processing being done for each request if it's going to get called for the same information by multiple requests in quick succession. You could make your own solution with caché/Iris, or look at something like redis.