Windows Server 2008 R2 Standard 6.1.7601 SP1 Build 7601
Selenium Standalone Server 3.8.1
Karma 1.7.1
ChromeDriver 2.34.522940 (1a76f96f66e3ca7b8e57d503b4dd3bccfba87af1)
Chrome Version 63.0.3239.132 (Official Build) (64-bit)
--
You received this message because you are subscribed to the Google Groups "headless-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to headless-dev...@chromium.org.
To post to this group, send email to headle...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/headless-dev/97340131-6a38-457b-8ee6-91b061d4a604%40chromium.org.
Unsuccessful (SLOW)
The next two screenshots are from the "Resource" section which corresponds to what I can see from the web server log:
Successful (FAST)
Unsuccessful (SLOW)
I'd look for differences in the BrowserMain and RendererMain threads first, and then go by exclusion. I.e. see until when things progress fine and at what point you see a longer delay between tasks than expected.
If everything is slower in general, maybe the browser doesn't have enough computing resources available?
If it's just network responses that are slow, maybe there's something misconfigured in the OS network stack?
--
You received this message because you are subscribed to the Google Groups "headless-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to headless-dev...@chromium.org.
To post to this group, send email to headle...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/headless-dev/09bac4bb-3570-43bd-8457-c1214d2c68b4%40chromium.org.
Windows NO PROXY, Chrome --proxy-pac-url SET
Windows PROXY
As you can see Chrome is showing three different scenarios.
Questions for you:
Eric,After focusing on network differences I discovered a difference between the "jenkins" (local user) user and my user (domain user). I ran Chrome GUI as myself and as the jenkins user and went to: chrome://net-internals/#proxyThis revealed my domain user was going through a proxy while the jenkins user was not.I set the proxy in Windows for the jenkins user, and that fixed the problem. I verified further by removing it and seeing the problem come back. So progress is being made!My IT Administrator is hesitant to set this proxy to this user across the ~100 boxes we have, as there may be unintended consequences. So I need to do some more investigation.Attempting Manual Proxy SettingI tried declaring the --proxy-pac-url option via Chrome CLI, but this did not solve the problem. Chrome still didn't use it as verified via net-internals/#proxy:Windows NO PROXY
Windows NO PROXY, Chrome --proxy-pac-url SET
Windows PROXY
As you can see Chrome is showing three different scenarios.
Questions for you:
Is there something about Chrome Headless that affects how the proxy is used?
Is there something about --no-sandbox that affects how the proxy is used? (A lot of people using Chrome Headless recommend to set --no-sandbox, not sure why.)
To unsubscribe from this group and stop receiving emails from it, send an email to headless-dev+unsubscribe@chromium.org.
To post to this group, send email to headle...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/headless-dev/8eb6a40a-9e4e-4866-bbed-e6be81ae6ba8%40chromium.org.
On 12 January 2018 at 16:25, <davida...@gmail.com> wrote:Eric,After focusing on network differences I discovered a difference between the "jenkins" (local user) user and my user (domain user). I ran Chrome GUI as myself and as the jenkins user and went to: chrome://net-internals/#proxyThis revealed my domain user was going through a proxy while the jenkins user was not.I set the proxy in Windows for the jenkins user, and that fixed the problem. I verified further by removing it and seeing the problem come back. So progress is being made!My IT Administrator is hesitant to set this proxy to this user across the ~100 boxes we have, as there may be unintended consequences. So I need to do some more investigation.Attempting Manual Proxy SettingI tried declaring the --proxy-pac-url option via Chrome CLI, but this did not solve the problem. Chrome still didn't use it as verified via net-internals/#proxy:Windows NO PROXY
Windows NO PROXY, Chrome --proxy-pac-url SET
Windows PROXY
As you can see Chrome is showing three different scenarios.
Questions for you:
Is there something about Chrome Headless that affects how the proxy is used?Quite possibly yes, headless is a content embedder (like chrome and third party browsers such as Opera) and it's possible various systems are not initialized properly in the headless code.Is there something about --no-sandbox that affects how the proxy is used? (A lot of people using Chrome Headless recommend to set --no-sandbox, not sure why.)I'd be surprised if that was the case, although it has various side effects.Why does setting the --proxy-pac-url not translate into an "Effective proxy setting" and instead only shown as "Original proxy setting"?