Browser pools: Reuse limited number of browsers (memory ⬇️, speed ⬆️)#86
Browser pools: Reuse limited number of browsers (memory ⬇️, speed ⬆️)#86
Conversation
5c6ff95 to
d6e1db7
Compare
|
Also see non-pooled load tests results here: They compare favourably to playwright JS client. |
|
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 👍🏻 👍🏻 |
9ad32b7 to
be10f16
Compare
caef4d7 to
0d531d0
Compare
d2c0921 to
ddb1ab3
Compare
|
Merging & releasing. Since it's opt-in, no need to worry in case there are problems. |
|
@ftes This is fantastic! Thank you so much. Yeah, I've dropped the browser pool size to half the |
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_casesconcurrency such as the default: 2x number of CPU cores).Pools are defined up front.
Browsers are launched lazily.
Closes #75