-
Notifications
You must be signed in to change notification settings - Fork 41
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
Limit browser implementation to hold a single browserContext #929
Conversation
To enable us to predicate and have a better idea of how much resource a test run will require, we want to restrict the number of browser- Contexts per vu to be one. This will ensure that a single test scenario which requires 1 vu and 50 iterations could work with a single browser and a new browserContext per iteration. Users will need to close the existing browserContext before creating a new one. We feel that this restriction along with scenarios should still work for majority of our users.
This check when NewContext is called on browser will ensure that we only ever have one browserContext at any one point. If a user wishes to create a new browserContext, they will need to close the existing one first.
common/browser.go
Outdated
browserCtx := b.context | ||
b.contextMu.RUnlock() | ||
if browserCtx != nil { | ||
return nil, errors.New("close the existing browser context before creating a new one") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know how you feel about this. I could change this in this PR (was going to do it in a later PR) so that we don't allow more than one browserContext
to be setup as we originally wanted.
@@ -50,8 +50,7 @@ type Browser struct { | |||
// A *Connection is saved to this field, see: connect(). | |||
conn connection | |||
|
|||
contextsMu sync.RWMutex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done a stress test on this mutex removal change, and it all seems to work still.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😱🤞🙃
Since all interactions with the browserContext in the browser are synchronous and no async actions occur on browserContext that could cause it to change between two or more goroutines - browser.context is set when browser.NewContext is called, and unset when browser.close is called.
b743c16
to
177cf7e
Compare
I haven't added a docs issue to this PR, as there are still two more PRs to create (as directed by the original issue). Once the final PR is done I will work on the docs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM 👍 Just a couple of small comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Minor skippable suggestions suggestions.
When multiple k6 instances connect to a single chrome instance, the page that is created by each k6 instance is also recreated in all k6 instances that are connected to the same browser. We don't do the same for browserContexts. When a page is recreated in one k6 instance for another k6 instance, the browserContext will not be there, so instead for now we should still work with the defaultContext.
Co-authored-by: ka3de <[email protected]>
Co-authored-by: İnanç Gümüş <[email protected]>
e413f52
to
0a37f5b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Description of changes
This PR is one of a few that will be used to help enforce a single
browserContext
perbrowser
per iteration. The reason for this change can be found in this directly linked issue and this overarching issue. The summary is that we want to be able to predict the resource requirements of how many browsers a test run may need, and the first step towards this goal is to be able to predict the number ofbrowserContext
s a test run will need.At the moment (in this PR) we enforce a single
browserContext
per iteration, which also means we allow the user toclose()
the existingbrowserContext
and create a new one withNewContext
. Any objects still associated to the previousbrowserContext
will be closed and the user will not be able to work with those objects. In a later PR we will change this behaviour so once abrowserContext
is setup, no otherbrowserContext
can be created, even if the existing one is closed.Checklist
Tasks