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
This is purely related how we start chromedriver.exe (and others) and wait until it is initialized. The current logic is:
Determine free available port on client side
Start chromedriver.exe process on this port
Polling via http to determine when the process becomes able to accept incoming connections on this port
The current logic is expensive and risky. Expensive because of we allocate new OS network connection just to check, risky because of there is "very small" chance that determined available port might be stolen in middleware.
How to improve? We can delegate determination of available port to chromedriver.exe.
c:\Users\Nick\.cache\selenium\chromedriver\win64\128.0.6613.119>chromedriver.exe --port=0
Starting ChromeDriver 128.0.6613.119 (6e439cfca4deda5954b0c74cde9b521c03cb31ad-refs/branch-heads/6613@{#1464}) on port 0
Only local connections are allowed.
Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully on port 50779.
We see ChromeDriver was started successfully on port 50779. where driver found available port itself.
Solution
Don't try to determine available port on client side. Just start the process and get the port, where the service is listening to, via console standard output.
Why
We remove "network tools" from selenium code base
We fix "race condition" when the same port might be considered as available by several clients (now we are not responsible to do it)
We do not allocate OS network connection just to check that "driver.exe is started and ready"
Benchmark
I have quickly implemented new approach and the results on my environment (desktop, pretty fast):
Just to start driver and exit: existing 523.35 ms versus proposed 21.09 ms
Constraints
Chrome/Edge driver v128+ only. Old versions don't output port to console.
Geckodriver 0.34.0 works, I didn't test older version yet.
I didn't test Safari driver yet.
Usage example
Everything stays as before, but faster and safer.
The text was updated successfully, but these errors were encountered:
@nvborisenko, thank you for creating this issue. We will troubleshoot it as soon as we can.
Info for maintainers
Triage this issue by using labels.
If information is missing, add a helpful comment and then I-issue-template label.
If the issue is a question, add the I-question label.
If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.
If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C),
add the applicable G-* label, and it will provide the correct link and auto-close the
issue.
After troubleshooting the issue, please add the R-awaiting answer label.
Feature and motivation
This is purely related how we start
chromedriver.exe
(and others) and wait until it is initialized. The current logic is:chromedriver.exe
process on this portThe current logic is expensive and risky. Expensive because of we allocate new OS network connection just to check, risky because of there is "very small" chance that determined available port might be stolen in middleware.
How to improve? We can delegate determination of available port to
chromedriver.exe
.We see ChromeDriver was started successfully on port 50779. where driver found available port itself.
Solution
Don't try to determine available port on client side. Just start the process and get the port, where the service is listening to, via console standard output.
Why
Benchmark
I have quickly implemented new approach and the results on my environment (desktop, pretty fast):
Just to start driver and exit: existing 523.35 ms versus proposed 21.09 ms
Constraints
v128+
only. Old versions don't output port to console.Usage example
Everything stays as before, but faster and safer.
The text was updated successfully, but these errors were encountered: