Performance Desktop Triggers

News Product News
1

Performance Desktop Triggers

Overview :mag:

Desktop triggers allow you to automatically respond to specific events on your local machine, removing the need to monitor for these events and performing a set of actions or starting an automation yourself.

We’re excited to bring you the new Performance Desktop Triggers which allow you to monitor resource consumption on your machine and respond to performance issues when they arise. Using performance triggers, you can prompt the user to close resource-intensive applications or send the CoE admin a performance report to proactively improve machine performance.

Whether using performance triggers in attended automations, as a background process, or monitoring your unattended machines, performance triggers will enable you to address performance issues before they become a problem and will help lead to higher rates of success among your automations. :champagne:

How does it work? :gear:

Performance desktop triggers will be available as a new activity in the UiPath.DesktopTriggers .Activities v1.0.0-preview package via the Official package feed (prerelease).

Package Feed
Package Feed1027Ă—643 29.7 KB

Within the activity you can designate which resource to monitor:

  • CPU :muscle:
  • memory :brain:
  • disk :cd: (coming soon)
  • network :satellite: (coming soon)

As well as the threshold and duration to monitor before executing the trigger event. You will also be able to monitor resource consumption for the entire system or a single process. This is useful when you’re monitoring resource-intensive applications such as Chrome or Zoom.

Activity
Activity661Ă—554 12 KB

The performance trigger will need to be used within a Trigger Scope activity and information related to the trigger event will be available via the Trigger Scope’s “args” property.

  • Computer ID
  • Monitoring start time
  • Elapsed time from monitor start to trigger event
  • Total system resource consumption
  • Top 10 processes and their resource consumption
    :warning: Only user-accessible processes are provided

Using this information, you can determine the most resource intensive user-accessible processes and make decisions such as closing unnecessary applications, notifying CoE/IT admins, or pausing/stopping processes.

Performance Desktop Triggers - Activity Guide.pdf (529.9 KB)

Prerequisites :clipboard:

  • Project compatibility must be set to “Windows”
  • Install the UiPath.DesktopTriggers.Activities and UiPath.WebAPI.Activities packages
  • Performance triggers must be used inside a Trigger Scope activity

Sample workflows :test_tube:

Performance Trigger - Attended Process.zip (4.6 KB)

Performance Trigger - Background Process.zip (4.3 KB)

Share your feedback :loudspeaker:

Feel free to share your thoughts and let us know how we can improve!

31 Likes
3

Hi @Tuan_Nguyen1,

I was this last week looking for exactly this. A windows event based trigger. Say a usb / hardware key is inserted and that trigger leads to some background / foreground automation.

I had plans to implement this using PowerShell listening to windows events. Thankfully now this package is going to make that idea redundant!

Thank you to the team. More feedback coming soon.

2 Likes
4

I am very intrigued by this new set of activities. I wanted to ask if you could expand more on the envisioned use cases? Is the aim to diagnose performance related issues, specifically with automations or just generally? Is it aimed at support for attended automation users? Are there any other key use cases that this was created for?

1 Like
5

I’m trying to understand how to use this based on what I see on my own machine.

From this trigger event, it is obvious that a spike in CPU (32.68%) exceeded the set threshold of 30%. But the list of top 10 user accessible programs that were snap shot during the spike do not seem to have contributed to the spike. The cumulative sum of percent values 1 through 3 are contributing less than 10% towards the spike, and two of the major contributors are UiPath programs that are filtered out of the advisory dialog.

image
image2300Ă—1185 167 KB

So, comes the first question:
Was the spike caused by a program that is inaccessible to the user? If yes, how would we know that a privileged program may be the actual culprit causing frequent spikes given that there is no access to such programs?

The Second question:
The User is being advised to close one or more programs that are not actually contributing to the problem. What happens if uninformed Attended automation users close a program such as explore.exe?

image
image832Ă—760 41.7 KB

In fact, regular end users may not even recognize cryptic program names. Can the trigger functionality be improved to capture user recognizable program names in addition to the internal exe names of the programs?

Thanks and I hope I have understood this new feature correctly.

1 Like
6

Hi Katharine, the key focus is to help with performance related issues, before, during, and after automation usage. We want to be able to proactively identify performance issues that may possibly impact automation success (resource-intensive applications, memory leaks, etc.) and take measures to improve performance in that specific environment. This can be done manually via an attended automation user or an admin with access to that environment. It can also be done automatically via background automation, but may run the risk of accidentally closing something you don’t want.

Most people will probably use performance triggers alongside other automations, but it can be used as a general performance monitor. For example, you can notify users of heavy resource consumption and recommended actions (close programs, restart computer, etc.) or even aggregate the performance trigger reports to understand trends in application usage and resource consumption throughout the day.

1 Like
7

Hi Andy, thanks for the feedback!

You’re correct that only retrieving the top 10 user-accessible processes is somewhat limiting at this time. Especially when items like antimalware, etc. may contribute a substantial amount of resource consumption. Unfortunately we don’t have a way to retrieve data on those specific processes (a permissions error is returned when trying to do so), but I will check with the team again to see if there’s anything we can do.

To your first question, while you may not know the culprit through the report, you’ll still be notified of the resource spike, the specific machine, and the time of the spike. You can then attempt to reperform the activities on that specific machine to understand which privileged processes are causing the performance issues.

Answering your second question, as a responsive attended feature, you would want to polish the user prompt further (filtering out designated processes or those with 1% or less consumption, displaying a notification instead of a choice if no viable choices are available, or using a mapping file as you mentioned). For the names in the process list, We used the process names since that can be passed directly into the Kill Process activity, but let me see if we’re able to expose the application name instead of the process name.

Question for you, since we are filtering out UiPath processes and potentially other designated processes like explorer.exe, do you think we need more than the top 10 processes? What would be a desirable number of processes?

1 Like
8

Yes. I am thinking if applying a limit of 10 is really valid. Going back to my JSON above, we can see that 7 of the programs don’t even have to be on that snapshot because their impact on CPU consumption is zero! Therefore the list of 10 user programs may lack merit in situations that are similar to this one.

Instead, would it be possible by design to include only processes that consume resources and ignore those that don’t? That way, the advisory will list programs that may potentially be impacting performance which makes it a lot more helpful than just the top 10.

I think this is a bit tricky. Back in 2019 I added a utility to my version of the RE Framework to fetch a list of processes and their titles. And here is the output of that flow as I ran it a few minutes ago:

image
image1130Ă—535 17.9 KB

Identify_Processes_By_Name.xaml (13.8 KB)

Most foreground processes seem to have a valid user-friendly Windows Title and where possible we may be able to use the title instead of the process name.

thanks

9

Thanks, this is very helpful. I’ll take a look and discuss what we can do with the team.

2 Likes
10

One possibilities with to his solution is that We can add machine validation to the RE Framework init state.

1 Like
11

Unidentified CPU Load was one of our main pain points. As you show the CPU Load is much higher than the public processes show. Especially when running in Azure, this happens all the time. So, it is good to have both the overall CPU Load and the list of highest using processes.

With respect to the naming, it is essential to include the PID to identify the right process as several processes can run with the same name:

image

Thanks,

12

Hi Maarten, thanks for sharing. I have some idea on how the PID would be important, but could you please share more background on how you would envision using it?

13

Well, that is easy … we (using other methods) checked for CPU Loads and if we found an excessive process (known) we’d kill it using its PID

image
image1257Ă—179 8.23 KB

The process name (imagename) is not always unique as shown above, PID is …

2 Likes
14

This will be very useful :clap::clap::clap:
Thank you UiPath!

15

Thanks @Tuan_Nguyen1 , this is very useful , i am looking for this from 2018 onwords , as it is not there i developed code for that when USB plug in the baby cry if not baby stops cry

3 Likes
16

Looks super useful for monitoring use cases.

17

Hi AndyMenon, we have found a way to pull privileged processes, but it is not performant. There is a ~15-20 second delay from the time the trigger event occurs to the time the process list is returned.

Given the delay, would you still find this helpful? We would most likely make this a configurable option (i.e. include privileged processes) in the properties panel. If unchecked, the unprivileged processes would be returned almost right away. If checked, unprivileged and privileged processes would be returned, but there would be a 15-20 second delay.

18

Hi @Tuan_Nguyen1 ,

Understood. I guess unless there is another way to make it performant, we have to first monitor common processes, and if we cannot attribute the performance lag to a common process, we have to pull the privileged processes (with the option enabled) to find the process(es) that are affecting system performance.

I want to just put this thought out here. Even if the monitor takes 15-20 secs to pull the list of processes, how does it measure in terms of reliability?

Let us say that the host machine is bogged down by notable disk and/or memory incursions. Will the monitor be able to still function within the 20sec mark? Or will it have trouble given that it is trying to query a heavily bogged down system? I hope I’m conveying my thought correctly.

Thanks for the update! :slight_smile:

1 Like
19

Hi all, the performance triggers v1.0.1 package has been released to the official feed with the incorporated feedback. It includes monitors for CPU, memory, and disk. We are working on network monitors and creating a Windows-Legacy compatible package.

Feel free to continue posting your feedback here. Thank you for all your help!

2 Likes
20

Thanks @Tuan_Nguyen1