You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey, @camiloribeiro, really nice example! I'm using it in a project I'm working on, thanks a lot for posting this!
BTW, this is not supposed to be an issue, it's more like just a comment on a minor glitch, but I couldn't find a better way to add such a comment besides via an issue, feel free to close it, ok? :)
My comment is about the usage of GParsPool. In your example, where you have 9 feature files, using a pool with 10 threads works like a charm. But since GPars waits for all threads to finish before assigning a new thread to a new element, it might be interesting to establish a balance between the number of threads you open and the number of features to be run.
For instance, if you had 11 features, where both the first one and the last one are really fast, and the ones in between vary in speed, in a pool with 10 threads the 11th feature would be blocked until the other 10 other features finished running, even though it's fast. So, in such a case, it might be interesting to have a pool with 3 threads, so that you reduce the amount of time wasted by threads that are blocked, waiting for others to finish.
All the best!
Felipe
The text was updated successfully, but these errors were encountered:
Hi @felipecao ,
Thanks for your explanation on this threads number optimization. If I understood correctly, you meant as following:
If I have three selenium nodes waiting for get test requests and run the tests, then I don't have to set threads number more than 3, because they will wait there anyway.
In case you are not familiar with selenium grid, selenium node can be treated just as a browser to run the UI test.
Hey, @camiloribeiro, really nice example! I'm using it in a project I'm working on, thanks a lot for posting this!
BTW, this is not supposed to be an issue, it's more like just a comment on a minor glitch, but I couldn't find a better way to add such a comment besides via an issue, feel free to close it, ok? :)
My comment is about the usage of GParsPool. In your example, where you have 9 feature files, using a pool with 10 threads works like a charm. But since GPars waits for all threads to finish before assigning a new thread to a new element, it might be interesting to establish a balance between the number of threads you open and the number of features to be run.
For instance, if you had 11 features, where both the first one and the last one are really fast, and the ones in between vary in speed, in a pool with 10 threads the 11th feature would be blocked until the other 10 other features finished running, even though it's fast. So, in such a case, it might be interesting to have a pool with 3 threads, so that you reduce the amount of time wasted by threads that are blocked, waiting for others to finish.
All the best!
Felipe
The text was updated successfully, but these errors were encountered: