Question
· Jul 13, 2017

.Net Gateway Parallel Calls – Optimal Number?

More calls in parallel to a single .Net Gateway can yield better performance, but too many could cause problems. What is the "Right" number? What do you do/recommend?

 

 

We have been using the .Net Gateway for quite a while now.

We are planning now to make even more use of it, functionality-wise, but more importantly, and the cause for my question, more heavily in the sense of concurrency.

 

Lately we built a mechanism that generates calls to the .Net Gateway sequentially, one at a time, but because of the planned multitude of calls, we want to move to calls is parallel, as we've seen this boosts performance.

On the other hand we've also experienced the fact that if we have "too many" processes calling in parallel then the Gateway "chokes" (that's the reason we built the "queue" mechanism to start with).

Note we also startup several .Net Gateways in parallel. Each servicing a different kind of activity. This of course also helps the parallelization and performance. But the question here concerns several Caché processes calling a single .Net Gateway at the same time.

So we'd like to have an optimum number of processes calling one Gateway in parallel.

Is there such a number? Are there some guidelines or rules of the thumb about the .Net Gateway parallelization?

 

Can you share your experience? What did you find worked best for you?

 

We're interested in hearing both what InterSystems folks have to say about this (Development, Support, SEs), and also our fellow developers out there.

 

Thanks

Discussion (2)1
Log in or sign up to continue

Hi Uri.

In my opinion, this possible hear only empirically through load testing on specific hardware.
It is also important and the interface between Caché and the world .NET, namely the number of calls made to a DLLBetter performance.

Sometimes the performance gain is observed when .NET refers to Caché (ADO.NET, eXTreme .NET Provider), and not vice versa (.NET Gateway). But it always requires a revision of the architecture.

By the way, for .NET Provider/ADO.NET there is Connection Pooling

Hi Uri,

Adding to what Vitaliy wrote I would like to share with you some input I got from our Development -

According to the question, there are a few situations to consider:

  1. Using a single gateway and multiplexing the data sent thru that one connection to a single gateway thread.
  2. Using a single gateway process with multiple threads communicating with individual Cache processes
  3. Using multiple gateway processes dedicated to different tasks that could have multiple connections/threads to each individual gateway process. 

Addressing this requires intimate knowledge of what the DotNet app is doing.  If the dotNet app has shared resources (making it single threaded) then option 1 is probably best.  Options 2 and 3 will tax the system with lots of process  creation and socket connections.  If they are using those options, it best to hold onto the connection established and not be constantly connecting and disconnecting.  With this in mind, they might combine the idea of multiplexing similar functions via a single connection that remains connected as a service.  Whether this uses 2 or 3 does not make a lot of difference, with the exception of situations where the DotNet application is not stable and can cause crashes, then it is best to isolate them to track down issues.