How to increase wait times of Browser Clickpath events beyond 60 seconds

[Bill_Emerson]

• Summary
• Problem
• Troubleshooting steps
• Verify the expected page load time
• Change the wait strategy
• Block long-running third-party resources
• Resolution
• Option 1 - Increase the monitor and event timeouts for Private Locations​
• Option 2 - Add a Click event​
• Option 3 - Add aJavaScript event ​
• Best Practices​
• What's next

 

Summary

Synthetic Browser Clickpath events can time out if a site is very slow. Sometimes, extending the time allowed for a Synthetic action to complete can improve a Monitor's availability. This article will help you add time to these long-running actions.

Problem

Browser clickpaths have a 60-second timeout per event and a 5-minute timeout for the monitor, after that you may see a hard timeout. How can this be handled when a site's performance is so slow that 60 seconds isn't enough time to complete an action? The timeout exists to prevent a monitor from using too much time on a testing location, but there may be scenarios when we must exceed the timeout.

Troubleshooting steps

Verify the expected page load time

If this browser clickpath is running on a

• Public Location
  • try accessing the site from computer that is outside of your network.
    
• Private Location
  • try accessing the site from an ActiveGate that is part of the private location.
  • Another reason for long durations is a problem with the network location of the ActiveGate. If this might be the case, also try accessing the site from other locations on your network to confirm the timings. 

Change the wait strategy

The browser clickpath may be waiting for something to finish downloading or change on the page that does not affect users or the scenario you are testing. If so, try using different wait criteria to see if you can find one that works for your situation.

• If nothing is changing on the page, for instance after filling in a field on a form, then try changing the wait to 'None'
• If a specific element is needed before moving on to the next event,
  • initially try 'Wait for next event', which waits for the locators of the next event to be available.
  • if that doesn't help, try 'Wait for a specific element to appear'
• As a last resort, use the "Wait for a specific period of time" and set it for 60 seconds.

You can find more information on waits here

Block long-running third-party resources

When checking the waterfall for a long running execution, some resources show as 'pending'. This means they did not download before the 60s allowed. If these resources are third-party and not affecting the user experience, they can be blocked in the browser clickpath's Advanced Setup. See Block specific requests 

If the page still can't load in the time allowed, you may have to build in extra events to your script to make the browser clickpath wait longer.

Resolution

Option 1 - Increase the monitor and event timeouts for Private Locations​

If the browser clickpath is only running on Private Synthetic Locations, the monitor and event timeouts can be updated using the Synthetic configuration API to increase the values of bmMonitorTimeout and bmStepTimeout.

The maximum settings are: 

"bmMonitorTimeout": 900000 (15 minutes)
"bmStepTimeout": 180000  (3 minutes)

If the browser clickpath will be running on Public Synthetic Locations, this solution will not help, as it only affects browser clickpath executions running on Private Synthetic Locations.

Option 2 - Add a Click event​

Since the default timeout is 60 seconds, per event, you can add an additional event after the event that is seeing timeouts to allow up to 60 seconds further wait time.

1. In the browser clickpath's settings, open the Recorded Clickpath
2. select Add synthetic event.
3. Set the synthetic event type to be Click
4. Set the new event to be added after the failing one
5. Set the wait time of the new event to 'Wait for Next event' or another suitable wait
6. Add a locator for the event.
   Select Type CSS and add body to the Input field
   
7. Set the wait time of the original, failing, event to be for specific amount of time, up to 60 seconds

This technique allows additional wait time. If more than 60 seconds is needed, another event can be added. By using a click on the body element, there is some validation that a page is loading. If there is no body element to click on, this step will fail signifying that the page really isn't even starting to get loaded after the initial step.

Option 3 - Add a JavaScript event ​

This technique is even simpler, but doesn't interact with the page at all so it doesn't have the validation from option 2. This option is useful if the site is so slow that even the html isn't loaded before the initial step has finished its wait.

1. In the browser clickpath's settings, open the Recorded Clickpath
2. select Add synthetic event.
3. Select the synthetic event type to be JavaScript
4. Set the new event to be added after the failing one
5. Leave the black code window blank.
6. Set the wait time of the new event to 'Wait for Next event' or another suitable wait
   
7. Set the wait time of the original, failing, event to be for specific amount of time, up to 60 seconds

Again, more events can be added for exceptionally poorly performing sites.

Best Practices​

• If a new event is added to a browser clickpath to increase the wait time, rename the new event to indicate it's just there to make the monitor wait longer. For example, something like "Click and Wait" or "Extend Wait Time." This makes its purpose clear to anyone else looking at the browser clickpath in the future.
• Try to limit the wait times to the minimum value that will allow the monitor to work. If waiting 30 seconds is enough to get 100% availability, then set the extra wait to 30 seconds. This will help the monitor continue to benchmark performance. We want the monitor to fail if the site starts taking more time than usual.
• Remember that the default total timeout of a browser clickpath is 5 minutes, that includes time used by these wait events. If a site is so slow that you need multiple wait events, you're only going to have time for a few actual functional events. This is another reason to limit the times of wait events to the minimum needed to pass.
• Having wait events may break up waterfall data over multiple events as the downloaded elements are spread across the original event and the wait event. So, the reporting of each event's timing could be fragmented.
• Adding wait events will not add time to Visually Complete or other metrics as we only count network times for elements. However, as noted above those metrics may be reported in different events depending on when the elements complete their download.
• Adding wait events may increase the cost of a monitor. Remember, Dynatrace Synthetic Monitors charge for actions, events that have network activity. If a page load is split across a navigate event and a wait event, you will be charged for both.

What's next

If none of these steps give you enough time to fully load a page, this site might just be too large or slow to be effectively monitored by a browser clickpath. You may have to rely on RUM to get performance data. But, if you feel that the Monitor is not reflecting the actual performance of the site, open a ticket with Dynatrace Support.

Please include:

• A link to the browser clickpath.
• The index number of the event that is failing.
• The name of the location where the browser clickpath is running.