Skip to content

Comments

Browser pools: Reuse limited number of browsers (memory ⬇️, speed ⬆️)#86

Merged
ftes merged 3 commits intomainfrom
feature/browser-pool
Oct 29, 2025
Merged

Browser pools: Reuse limited number of browsers (memory ⬇️, speed ⬆️)#86
ftes merged 3 commits intomainfrom
feature/browser-pool

Conversation

@ftes
Copy link
Owner

@ftes ftes commented Oct 24, 2025

Experimental browser pooling. Reuses browsers across test suites.
This limits memory usage and is useful when running feature tests together with regular tests
(high ExUnit max_cases concurrency such as the default: 2x number of CPU cores).

Pools are defined up front.
Browsers are launched lazily.

Closes #75

@ftes
Copy link
Owner Author

ftes commented Oct 25, 2025

Also see non-pooled load tests results here:
ftes/phoenix_test_playwright_example#2

They compare favourably to playwright JS client.

@s3cur3
Copy link
Contributor

s3cur3 commented Oct 27, 2025

I am very interested in this, not for any potential speedup, but because when I run a large test suite in CI, some of which is Playwright tests and some of which is normal unit tests, I frequently see timeouts within the PhoenixTest.Playwright GenServers because we failed to hear back from Playwright within 1.5x the specified timeout (not timeouts due to client code saying something like "click such-and-such button within 2 seconds"). It'd be nice to be able to run the full test suite with max parallelism, while limiting the number of concurrent Playwright browsers to try to make sure they're not resource-starved.

@Valian
Copy link

Valian commented Oct 27, 2025

I am very interested in this, not for any potential speedup, but because when I run a large test suite in CI, some of which is Playwright tests and some of which is normal unit tests, I frequently see timeouts within the PhoenixTest.Playwright GenServers because we failed to hear back from Playwright within 1.5x the specified timeout (not timeouts due to client code saying something like "click such-and-such button within 2 seconds"). It'd be nice to be able to run the full test suite with max parallelism, while limiting the number of concurrent Playwright browsers to try to make sure they're not resource-starved.

Exactly the reason why I made #75 👍🏻 👍🏻

@ftes ftes force-pushed the feature/browser-pool branch from 9ad32b7 to be10f16 Compare October 28, 2025 07:54
@ftes
Copy link
Owner Author

ftes commented Oct 28, 2025

I've pushed a v2 (curated the initial AI implementation).
Now, browser pooling is opt in. Pools are explicitly defined up front for full control.

Before merging and releasing, would you care to test it in your projects? @s3cur3 @Valian
See usage docs in PhoenixTest.Playwright.BrowserPool.

@ftes ftes force-pushed the feature/browser-pool branch 5 times, most recently from caef4d7 to 0d531d0 Compare October 28, 2025 08:21
@ftes ftes changed the title Browser pool: Limit number of browsers Reuse browsers to limit memory consumption (browser pools) Oct 28, 2025
@ftes ftes changed the title Reuse browsers to limit memory consumption (browser pools) Browser pools: Reuse limited number of browsers (memory ⬇️) Oct 28, 2025
@ftes ftes changed the title Browser pools: Reuse limited number of browsers (memory ⬇️) Browser pools: Reuse limited number of browsers (memory ⬇️, speed ⬆️) Oct 28, 2025
@ftes ftes force-pushed the feature/browser-pool branch from d2c0921 to ddb1ab3 Compare October 28, 2025 19:22
@ftes ftes merged commit 00e75c6 into main Oct 29, 2025
1 check passed
@ftes
Copy link
Owner Author

ftes commented Oct 29, 2025

Merging & releasing. Since it's opt-in, no need to worry in case there are problems.
Still very happy to hear any feedback.

@s3cur3
Copy link
Contributor

s3cur3 commented Oct 29, 2025

@ftes This is fantastic! Thank you so much. Yeah, I've dropped the browser pool size to half the schedulers_online and the overall reliability seems much better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feature request: Limit number of concurrent e2e tests

3 participants