-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How can I reuse the same chromium instance? #100
Comments
I have the feeling that my process is taking up so long because this library is creating a new Chromium instance over and over. Does it make sense? |
Not really practical with how the initialisation of the Grover instance occurs (ie the content to be rendered passed through the initialiser) and somewhat goes against the direction the project has been moving. In #53 the schmooze gem was removed due to the way it leaked Chromium processes (through how it uses the GC to clean up workers), however I can imagine it would be possible to use something like schmooze to achieve what you're after, I just don't see it happening within this project. Schmooze boots up a single NodeJS instance and would allow re-entrant calls, although TBH I'm not sure if it would support persisting the Puppeteer instances across calls. Another option would be to consider something like the Ruby Puppeteer port, but I found it wasn't as performant as calling to Chromium through NodeJS. I do like to see Grover support as many use-cases as possible, but this feels like quite a significant side-step and not really something I see being in Grover. |
#115 allows you to access a remote existing chromium. Helpful here? |
@abrom Andrew, first of all, huge props for this amazing project. I would greatly appreciate a way for Grover to use a long-running Puppeteer instance. The gem doesn't have to do all the work by itself, we could even use a systemd service or Ubuntu or something (and just provide the instructions in the readme for the ones that want to use it). I think that it would greatly reduce the time to generate PDFs since it would avoid the Chrome startup time every time someone clicks the "download PDF" link on our application. |
Per my previous comments, I'm not convinced this is the path forward for Grover.. However some relatively simple tweaks would allow you to create a single Grover instance with a re-useable NodeJS/Puppeteer/Chromium setup. See https://github.com/Studiosity/grover/compare/reuse-processor The Grover instance method definitions need to change of course because you're going to want to pass different URL/options in per conversion!
N.B
In terms of how much of an improvement it makes.. short answer.. some, but not as much as you'd think (if anything):
Compared to the current code:
... practically identical 😉 |
@abrom Thanks so much for the detailed answer, it would take me a long time to benchmark this. |
Well the comparison was pretty simplistic. You'd really need to run it hundreds of times and compare not just the runtime but the memory usage etc too |
I would like to use the same Chromium instance every time, so only a new tab/page would be open for a new request.
Is that possible with Grover?
Thanks a lot
The text was updated successfully, but these errors were encountered: