I would like to understand the high level architecture on how k6 is built and how it works internally. Is there any supporting documents for this. I found my self and ended up without any.
Can someone help me in understanding the architecture and how works internally in high level.
@kaushik, unfortunately there isn’t such a document. There used to be one, but we haven’t updated it after some major architectural changes, so it will be more confusing than helpful at this point… Most of the code is reasonably well commented, but an architectural diagram and explanation will definitely make things easier for newcomers…
We will try to update it soon, but until then, do you have some specific questions you’d like to ask? All of the k6 OSS developers frequent this forum and we’ll try to help.
Basically that was my intention too. Thought I have some understanding about tool wanted to understand the behind works how k6 does things.
I know k6 works on VU concepts where each VU creates a traffic for application under test.
Some questions are below:
- Components involved in k6 at least some high level for easy understanding
- How each commands in k6 works internally. Example is when we use http.post() what happens internally to make things work.
- Basic understanding between Connectivity part of go and js
- How k6 test runner works internally
The answer to the first question is a big one that probably deserves its own page in that future architecture doc However, if you’re exploring the codebase, I suggest starting you exploration in
cmd/run.go and following how everything works, you’ll hit the majority of the big components and how they work together.
The answer to 2. and 3. can be found by looking at things in these folders:
Basically, k6 uses the goja runtime to execute JS code and we also have some glue code (which btw is currently in the process of being significantly changed) to bridge our own internal modules (e.g.
k6/http and any other
k6/ module, including xk6 ones) and make them accessible as JS APIs that users can
import in their scripts as if they were native ones.
The last question is also a bit too broad and probably also should be its own separate document, but take a look at these files, they are reasonably well documented: