- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 125
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
Implementing a persistent-session mechanic. #171
Comments
For anyone running into the same issues as I am, I wrote a library that operates similar to this one existing one that addresses these features, due to not having a reply to this issue after two weeks. |
Hello 👋 I do this on my free time. Moreover, I'm the only maintainer. So please, be gentle and patient. Glad you find a way to fix your issue. If you want it to be included in node-html-to-image, feel free to explain your solution. |
I'd be happy to just implement a pull request for this, which was what I would've offered to do if I got a reply. To fix this issue I created an instance manager class, where one browser was launched. Instead of creating many browsers, the one browser creates many tabs (as blink can spawn worker threads to render multiple documents at once, using multiple browsers does the same with more overhead). Each tab has it's own class wrapped around it, which has a flag for if it's in use or not. Whenever there's a render job requested, it iterates and picks the first free tab (or loops over until one's free), renders it, then returns the image without closing the browser. I thought about doing a PR, but it'd have required refactoring all the code, which would be a lot of effort before getting a response to an issue |
@Furry did you make performance benchmark between your solution and node-html-to-image that uses puppeteer-cluster? I would be interested by the result. It could help to take a decision on this 😄 |
Not to dig up the dead here, but at the time of development I did yes; the difference stemmed from using persistent browser sessions tied to the applications lifetime rather than a new browser context. The performance hit that you get by spawning multiple puppeteer instances is incredibly large, especially considering windup time when you can simply render a new page with puppeteer using tabs instead of brand new clustered contexts, I don't use puppeteer often (and have since swapped to playwright) but the issue is pretty old and #80 talks about that bit too. |
Hiya there o/
I have two questions,
1.) Is there a difference in performance between using a Puppeteer Cluster versus using a singular puppeteer session with multiple tabs all rendering at once?
2.) Is there a way to have a persistent session so that in an environment (in my case, an API), the puppeteer instances wouldn't have to relaunch each time to render tabs?
The text was updated successfully, but these errors were encountered: