Job starting on Cloud Platform has a 10-15 seconds delay

Help Automation Cloud
1

Hi there,

I am experiencing a delay in starting a job using the platform.uipath.com orchestrator. I’m using the API to start a specific process on a specific robot and sometimes there is a 10-15 seconds delay between the time the job appears in the orchestrator, and shows as “Pending” and the time the robot starts working on it when it changes to “Running”. It’s worth mentioning that when I do this through an orchestrator that we host, the job always starts with very little delay 1-3 seconds. Is this an intended behavior for the cloud platform?

I’ve seen on the forum that some people mentioned this delay a while ago, but for them, the 15 seconds was too soon and they wanted to increase it. In our scenario, in which the job is triggered by a message from the user in a chat interface, it needs to start ASAP.

I can provide more details about the setup if it helps, but I wanted to first see if this rings any bell. Maybe I’m missing something easy, like a setting somewhere.

Thanks,
Razvan

2

@RazvanDinu, Actually platform.uipath.com is hosted on the UiPath’s server so you may expect some delay in communication between the client and server, as request pass through many channels. Also, you need to check your internet speed.

#HappyRobotics

3

hi
welcome to UiPath community
well there can be two reasons like
–either the robot where we are running this process is been referred by some other process at the time we execute this process, because the status “Pending” usually occurs when the robot is in another process execution
OR
–it can be due to API connection, may slow down due to the internet connectivity and its integration, kindly check with the system performance where we are executing this process and also the network connectivity
hope the network connectivity wont have much impact and its all upon the system performance

Cheers @RazvanDinu

4

Thanks @vikaskulhari. The ping to platform.uipath.com is around 50ms and internet connection is pretty good. Is there any logging option I can enable to check if the robot itself has problem connecting to the orchestrator?

5

It is definitely not the case for the first option. By design only one job is running at a time and the next job is started through the API after the current job finishes i.e. the status is “Finished”. Also, the API itself seems to be working fine, as I’m pooling the job status every second to check if it finished and it responds under 1 second.

From my perspective, it’s like the UiPath Robot would pool the orchestrator every 10-15 seconds for new jobs, rather than have a live connection. Any idea on the mechanism the robot uses to stay connected to the orchestrator?

2 Likes
6

I hope its not so because when the machine where we want to execute our process, is connected with the orchestrator, ITS ALWAYS AVAILABLE and will EXECUTE THE PROCESS THE MOMENT WHEN THE JOB IS TRIGGERED…
and i hope there is something we lag with API trigger and i would like to know whether it impacts to a large scale to our process, is it so buddy
Cheers @RazvanDinu

7

Hi @RazvanDinu

It might be just Cloud Platform having a slower moment, in the end.
This would prove that:

It’s worth mentioning that when I do this through an orchestrator that we host, the job always starts with very little delay 1-3 seconds.

It might also have something to do with the heartbeat that the Robot uses to keep staying ‘in touch with Orchestrator’. It should be that though, because I would imagine Orchestrator should ping the robot immediately when there is a valid process to be run.
More about the heartbeat:

image
image790×167 10.2 KB

However, I would first try to debug what is happening.

You have mentioned that you are monitoring the processes status. Does the process show up on the list the moment you start it with the API call? I would setup the monitoring and look for the delay (when monitored by API) between the Start Job API call and the process to show up as Pending/In progress in your small monitoring sequence.

3 Likes
8

Thanks @loginerror. I will investigate over the next couple of days and come back with more details. I need to get to the root of it this week.

9

Just to let you know, I’ve tested it just know with a simple HelloWorld process and it starts immediately when I launch it on my Machine via the API call.
Not sure here, but it could therefore either be:

  • load on Cloud Platform at the time you were testing last time
  • maybe the complexity of the process itself?.. (just to be sure, you can also test with a simple one that only displays one message box)
1 Like
10

I managed to figure this out, so I am posting the solution in case anyone else will run into the same issue.

The problem was that the version of the client (robot service) I was using was too old, it was a 18.4.5 installation. I’ve upgraded to 19.4.4 and it’s working as expected. I figured this out by looking into the Windows Application logs:

46
461816×1348 246 KB

So, I believe what was happening was that it was not able to initiate a socket connection and was reverting to a pooling mechanism which was set at 30s (probably at the same time with the heartbeat @loginerror mentioned).

Thanks for the help everyone!

2 Likes
11

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.