I'm using Chrome in headless mode via CDP (Chrome devtools protocol) to do HTML to PDF conversions. Works well but I do not trust Chrome to run forever and want to build a guardian service to monitor its responsiveness and if necessary kill the process and relaunch it.
What would be a good indicator of health? What I'm looking for is a low overhead test I can perform at fairly frequent intervals so that the restart latency is minimised.
I could try to perform some kind of CDP command if anyone has a suggestion and a reliable way to determine success.
I can't think of anything else, that's why I've thrown it open for suggestions.
My best suggestion for this case is to use the Target domain. Listening to some of the events that are fired from the target domain will give you some information regarding the state of your browser, such as TargetCrashed.
On top of that, you could use basic domains like Runtime (provides the evaluate method), SystemInfo or Browser to send the browser requests in order to check its health.
Related
With an increasing mobile user base I would like to be able to gauge a baseline for site performance. Typically I can do this using chrome dev tools, checking when DOMContentLoaded finishes, and checking all my javascript tags to make sure they're in acceptable threshholds. How would I go about automating this so I can create performance dashboards?
Maybe phantomjs, selenium can do this? What headless chrome implementation could I use to achieve this.
You can use Lighthouse to capture a variety of performance metrics.
For real user metrics, you can instrument your app however you see fit with the User Timing API.
I'm trying to debug difference between HTTP/1.1 and HTTP/2.
Is there any possibility for disabling HTTP/2 in chrome or chromium?
I couldn't find this option flag in chrome 56. I have tried chromium 58 with flag --disable-http2:
./Chromium.app/Contents/MacOS/Chromium --disable-http2
But content is still delivered with HTTP/2 protocol after using this flag:
For what it is worth, the flag works.
The issue is that you need to quit EVERYTHING Chrome for it to take effect. Including plugin shims and other chrome tabs and so on.
It is not enough just to add the command line switch.
An easier way to achieve something broadly equivalent is to use an HTTP Proxy, like https://www.telerik.com/fiddler. This adds negligible additional time to your requests, and (as far as I know) doesn't support http/2 at all (yet); even if it did, I'm pretty sure it would be much easier/practical to switch behavior in than restarting all your Chrome windows.
The advantage of this approach is that it takes effect immediately - disabling and reenabling HTTP/2 becomes as easy as starting and stopping the proxy, without messing with the (if you're anything like me) dozens of Chrome tabs you have open, to StackOverflow and elsewhere :)
What happens when you try doing the same thing in WebPageTest (select Chrome as the test agent and add the command line switch in the Chrome tab under advanced settings)
Here's a test I did for my personal site just now and the flag appears to work OK (if you look at the response headers you'll see HTTP/1.1)
https://www.webpagetest.org/result/170322_1B_ab8656afcfb8bcc4103e9872ff56c28b/1/details/#waterfall_view_step1
I have seen the same problem created by a firewall running in proxy mode vs flow mode.
The firewall would buffer the entire file so it could scan it then pass it along vs scanning the individual packets.
https://docs.fortinet.com/document/fortigate/6.4.4/administration-guide/721410/inspection-modes
The problem would only happen when using http2 and might have something to do with http request priority not being handled properly or it forced it single threaded.
We would have a video request start with a low priority that would stall then start causing other file downloads to be delayed. Then there was a api poler in the background coming in with high priority requests. After a few high priority requests were blocked chrome would cancel the low priority video.
It would happen in other cases but the video made it very reproduceable for us.
https://medium.com/dev-channel/javascript-loading-priorities-in-chrome-57c54cfa6672
https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/
https://blog.cloudflare.com/http-2-prioritization-with-nginx/
https://calendar.perfplanet.com/2018/http2-prioritization/
We set it back to flow mode on the firewall and the problem went away.
Afterwards the downloads all happened in parallel with no blocking or stalling in the chrome network waterfall.
I've been writing an extension that allows the user to issue voice commands to control their browser, and things were going great until I hit a catastrophic problem. It goes like this:
The speech recognition object is in continuous mode, and whenever the onerror: 'no-speech' or onend events fire, it restarts. This way, the extension is constantly waiting to accept input and reacts whenever a command is issued, even after 5 minutes of silence.
After a few days of of development, today I reached the point where I was testing it in practical use, and I found that after a little while (and with no change to anything on my part), my onend event started firing constantly. As in, looking at the console, I would see 18,000 requests being made in the space of three seconds, all being instantly denied, thus triggering onend and restarting the request.
I'm aware that it would be optimal to wait for sound before sending a request, or to have local speech recognition capabilities without the need for a remote server, but the present API does not allow that.
Are my suspicions correct? Am I getting request limited?
Are my suspicions correct? Am I getting request limited?
Yes
I'm aware that it would be optimal to wait for sound before sending a request, or to have local speech recognition capabilities without the need for a remote server, but the present API does not allow that.
To hide the IP source of your request you can use anonymizer networks like Tor, though it will not be fast.
It's naive to assume Google will spend resources to process all audio being recorded on your system. In your application development it is better to rely on API which provides at least some guarantees. It could be either commercial API or open source implementation like CMUSphinx.
With CMUSphinx, you can also properly implement command keyword detection and increase accuracy by specifying the grammar of the commands.
You could also use a Voice Activity Detection (VAD) algorithm to detect when a user is talking. This can be done by either setting a volume threshold or a frequency threshold (Human speech is usually less than 400hz for example). This way, you won't send useless requests to Google unless those conditions are meant. I would not recommend using Tor as this would significantly increase latency. CMUSphinx is probably the best local system option, but if still want to use a web-based service, I would recommend either using a Voice Activity Detection algorithm or finding a different web-based software.
I need to reverse-engineer some javascript application which does authorization using facebook auth.
Facebook auth window pops up, asks for my permissions, and gets closed instantly, so I am unable to grasp anything from the performed action, as it's too fast.
The problem is that neither Chrome DevTools, nor Firefox Firebug does display network activity for child windows like OAuth permission.
Is there a way to enable FULL network log? An extension, whatever? (It better be free and easy to use)
If you're using Windows, you need Fiddler. If you're not, you'll have to settle for Wireshark. Wireshark is more-general and an amazing tool, but Fiddler does a much better job for HTTP and SSL conversations like you're going to be examining.
Today, i observed an interesting behavior. I am using windows XP-sp3 OS.
When i open a new tab in Google Chrome & view the task manager, a new process is created.
But, after some time, this process is terminated.
Why it is showing such kind of behavior? Is it due to system call vfork()? Does the child process immediately call exec()?
Does it happen only with Google Chrome or all other browsers behave in a similar fashion?
AFAIK Chrome maintains one process for each tab, also one process for some plugins too. They preferred multi-process architecture over multi-threaded one because when you are making network application which communicate with network all the time, you can expect to receive packets which can garble the memory. So having multi-process will prevent all but one process, as opposed to multi-threaded will kill the the tabs.
You can enlighten your self on following blog:
http://blog.chromium.org/2008/09/multi-process-architecture.html