calculateRoute vs. startCalculateRoute

[Pete]

Hi,

I just started evaluating xServer 2 API, my tests just calculate a simple route between point A and B.

I am using the provided C# client code.

I first used the slightly easier synchronous calculateRoute method, a single http request is used to get the response.

I then started using asynchronous startCalculateRoute, now at least three http requests are used to get the response, the first to create a new job, the second to watch the job and the third to fetch the response.

If I only have a single RouteRequest with a simple route between A and B, the synchronous single call seems faster.

I understand that if the request becomes more complicated and takes longer to process on the xServer side, it makes more sense to use startCalculateRoute.

Also if I have many RouteRequests which I can fire off in parallel, the asynchronous way should work better.

So my question is are there any best practices for when to use calculateRoute vs. startCalculateRoute.

I think in our case it would be helpful to have something like startCalculateBulkRoute where I can pass in many RouteRequests and still only used 3 http requests (+ some Watch calls) even if I have hundreds of requests.

[Bernd Welter]

Hello Pete,

from my personal perspective the asynchronous approach is meaningful under specific conditions:

• If the transaction type is in fact complex enough to provoke a long calculation time (this happens with international routes of >1000km or if you apply specific settings such as PTV_SpeedPatterns in combination with TimeConsideration.ExactFromStart or ExactAtArrival).
• If there's a bulk implementation which enables you to get a status progress, e.g. in bulk geocoding where you can get "transaction(1234...) has already geocoded 50 out of 500 input addresses. You can build a progress bar and estimate also "end of process". This also works fine with distance matrices. (I hope we will offer a progress in tour optimization, too. This was already the case in xTour 1 / improvement phase)
• If you want to enable a user to interrupt a transaction (e.g. tour optimization) and consume the "best solution found so far".
• If you want to proceed in your client applications main thread till you get triggered for the "response available".

My gut feeling: start with synchronous implementation in xRoute as long as you don't benefit from one of the motivations mentioned above. It is good if you are aware of the option of asynchron protocol but this could also make your application more complicated if you don't benefit.

Furthermore: be aware that the AZURE load balancer disconnects you if a transaction exceeds a timeout of 3 minutes. So if you need that long the asynch is not only a convenient alternative but also the only way to successful response!

Best regards,
Bernd

PS:
Please be aware htat "firing hundred requests in parallel" should not be done by design (part of the licensing statement's fair usage policy)

[Pete]

Hi Bernd, thank you for your reply.

In your PS you mentioned

> part of the licensing statement's fair usage policy

I can not find these online, can you point me to the limits of API usage, e.g. requests per second?

I know this may depend on the kind of license we will use, but I like to know how hard I could hit the xServer internet.

Pete

[Bernd Welter]

Forwarded to Isabel - Product Management...

AFAIK there's a statement that you are supposed to send not more than 8 parallel requests but I prefer Isabel to handle this topic properly

[Bernd Welter]

Here's Isabel's statement:

Hallo Bernd, vertraglich gibt es keine Begrenzung. Wir appellieren nur an uns auffällige Kunden sich an das von uns vorgeschlagene Limit von 8-10 parallele Requests zu halten.

translated:

There's no contractual limitation. If the volume of a customer is eye-catching we recommend to them to send not more than 8-10 requests in parallel

Best regards,
Bernd