Hello,
When executing a test directly from Ranorex Studio (8.1) on my local machine, the tracking of elements on a webpage are very very slow (can take up to minutes if I allow the test to wait that long). However, when running the same test on a virtual machine through Jenkins, element tracking is very quick and smooth. My issue exists across browsers. Has anyone experienced an issue like this? Or are there steps I can take diagnose my problem? Sorry that this is not a very specific question.
Thanks
Element tracking very slow on local machine
Re: Element tracking very slow on local machine
I have the same issue on my local machine. It doesn't take minutes to track elements but certainly is very slow (up to 30 seconds). Haven't tried it in a virtual machine yet but it is a very frustrating performance issue.
Also when I'm recording, key sequence action is very slow. After I finish typing and waiting for a while, the first letter appears and gets recorded. Sometimes it is so slow that multiple key sequence actions get created because Ranorex thinks I am typing multiple times or something.
Also when I'm recording, key sequence action is very slow. After I finish typing and waiting for a while, the first letter appears and gets recorded. Sometimes it is so slow that multiple key sequence actions get created because Ranorex thinks I am typing multiple times or something.
Re: Element tracking very slow on local machine
Hi,
If I understand your problem right, the problem is with the speed of element identification (during test runtime), not actually tracking them with Spy?
Could you please share an example of xpath you have a problem with? And Ranorex snapshot (NOT screenshot) would help too. Also, are you using some kind of antivirus on desktop, which may be not installed on VM?
If I understand your problem right, the problem is with the speed of element identification (during test runtime), not actually tracking them with Spy?
Could you please share an example of xpath you have a problem with? And Ranorex snapshot (NOT screenshot) would help too. Also, are you using some kind of antivirus on desktop, which may be not installed on VM?
Pavel Kudrys
Ranorex explorer at Descartes Systems
Please add these details to your questions:
Ranorex explorer at Descartes Systems
Please add these details to your questions:
- Ranorex Snapshot. Learn how to create one >here<
- Ranorex xPath of problematic element(s)
- Ranorex version
- OS version
- HW configuration
-
- Posts: 13
- Joined: Wed Dec 06, 2017 8:33 pm
Re: Element tracking very slow on local machine
Hi everyone,
I'm with same problem about slow to run tests.
Ranorex takes too long to to find and click.
I use on VM Windows 10, there' no antivirus, start with administrator.
Ranorex version is 9.1(trial), we're trying to create test case to see if Ranorex is ideal tool to automate.
Is there something to do ?
Thanks for all.
I'm with same problem about slow to run tests.
Ranorex takes too long to to find and click.
I use on VM Windows 10, there' no antivirus, start with administrator.
Ranorex version is 9.1(trial), we're trying to create test case to see if Ranorex is ideal tool to automate.
Is there something to do ?
Thanks for all.
- Attachments
-
- win_10_slow_to_find.rxsnp
- (2.73 MiB) Downloaded 8 times
-
- LOGS.zip
- (7.65 KiB) Downloaded 9 times
- Support Team
- Site Admin
- Posts: 12167
- Joined: Fri Jul 07, 2006 4:30 pm
- Location: Graz, Austria
Re: Element tracking very slow on local machine
Hi Douglas,
This may be caused by a combination of the total number of elements and the machine's hardware specs. Ranorex is finding most elements on the first try ("TimesSearched" column), however, I do see one full search can take up to 9 seconds. Below is an excerpt from one of the performance logs of the elements taking the longest.
While we generally do no expect elements to take this long to find, this can occur occasionally within applications with a lot of elements (such as a table). In the provided Snapshot, we can see over 3,300 elements that Ranorex must search through to find the proper element. With this amount of elements, it can take some time to process and lower end machines may take longer.
Generally, there is not much to do to remedy this except upgrade the machines hardware and/or reduce the number of elements existing in the application under test (such as filtering the number of rows in a table; not always possible). Note, this speed will likely be the same with any object based automation program as there is simply a lot to process and that can take some time.
Also note, your trial is fully supported and we will be happy to help further investigate this issue one-on-one if you wish. Just shoot us an email with a link to this forum thread - [email protected].
Cheers,
Ned
I hope this information helps!
This may be caused by a combination of the total number of elements and the machine's hardware specs. Ranorex is finding most elements on the first try ("TimesSearched" column), however, I do see one full search can take up to 9 seconds. Below is an excerpt from one of the performance logs of the elements taking the longest.
Code: Select all
+---------------+----------------+-----------+-------+
| TimesSearched | LastSearchTime | TotalTime | Found |
+---------------+----------------+-----------+-------+
| 1 | 8910 | 8917 | TRUE |
| 2 | 3044 | 6163 | TRUE |
| 1 | 9049 | 9049 | TRUE |
| 1 | 7672 | 7672 | TRUE |
| 1 | 8317 | 8317 | TRUE |
| 1 | 7529 | 7529 | TRUE |
| 1 | 7571 | 7571 | TRUE |
| 1 | 7597 | 7597 | TRUE |
| 1 | 7657 | 7657 | TRUE |
| 1 | 7649 | 7649 | TRUE |
| 1 | 7714 | 7714 | TRUE |
| 1 | 7626 | 7626 | TRUE |
| 1 | 7671 | 7671 | TRUE |
| 1 | 7601 | 7601 | TRUE |
| 1 | 7639 | 7639 | TRUE |
| 1 | 7509 | 7509 | TRUE |
| 1 | 7574 | 7574 | TRUE |
| 1 | 7713 | 7713 | TRUE |
| 1 | 7629 | 7629 | TRUE |
| 1 | 7549 | 7549 | TRUE |
+---------------+----------------+-----------+-------+
Generally, there is not much to do to remedy this except upgrade the machines hardware and/or reduce the number of elements existing in the application under test (such as filtering the number of rows in a table; not always possible). Note, this speed will likely be the same with any object based automation program as there is simply a lot to process and that can take some time.
Also note, your trial is fully supported and we will be happy to help further investigate this issue one-on-one if you wish. Just shoot us an email with a link to this forum thread - [email protected].
Cheers,
Ned
I hope this information helps!