Open sravani93 opened 6 years ago
Component | Version |
---|---|
Operating system | Debian GNU/Linux buster/sid |
Node.js | v8.4.0 |
Chrome/Chromium/... | 61.0.3163.91 |
selenium + chrome headless is better, but there's some bugs with it.
hi @sravani93 launching the same version of chrome with the same debugging port is going to be problematic, Can you share a test case so we can reproduce? Thank you.
@samccone i think it's a single chrome launched just once. but essentially with 150 different instances of chrome-remote-interface connecting to that one port. Pretty exciting. :)
@sravani93 interesting challenge. we're not sure where the problem is. it could be the web/websocket server at 9222 or it could be the IPC buffer going between renderer and browser (or something else entirely).
This would require some more investigation to figure out, and doing some changes to chromium.
There's one alternative that you could try out to see if it helps though.
Using childProcess pipes as protocol transport
A few months back we enabled pipes to act as a protocol transport, rather than using a websocket. Performance-wise, it's not substantially different, but we see the main benefit being security. Anyhow.. if the bottleneck here is indeed near the TCP socket, then this would avoid that entirely.
pipe
the stdio fds 3 and 4. (see here)send()
method and a message
event. That hooks in at a level pretty internal to chrome-remote-interface, so you'll probably need changes there, too. :)Anyhow, after all that you shoulddddddd be able to try this out.
(as I type all this I realize a probably easier solution is to fork puppeteer and merge those two PR branches in and then attempt to recreate your situation using the puppeteer API)
Anyhow, good luck!