You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
K6 has historically had only synchronous calls as it also did not have an event loop in order for asynchronous calls to be implemented.
This is no longer the case:
There is now an event loop
A bunch of APIs are now asynchronous or have asynchronous counterparts.
Unfortunately mixing synchronous calls with asynchronous ones leads to blocking the event loop effectively slowing down the execution of asynchronous ones.
Old users will likely have particular problems as they might want to start using a single asynchronous API call. But it will seem to work badly if there are also a bunch of synchronous calls blocking the event loop, delaying the return of a result and potentially making the test fail due to it.
A good example of this happening was already reported, with sleep.
Solution
During discussions about (in early December) #2728 and the #2863 it was discussed if we can warn users when they call synchronous calls in async functions. This obviously depends on us being able to detect that we are currently in async function at all.
At the time it wasn't certain if that will be possible and later, as #2863 was not merged, work on this stalled, and I never even started working on possible solution.
Currently, it seems like goja does provide us a way to know we are in an asynchronous context. But even without it in practice the moment the first call in the event loop is over - any consequent call is within an asynchronous context, by definition as it need to originate from an asynchronous operation.
Problems:
Scope:
I would argue there should be a way to detect whether we are in async context by a JS module, and then it can decide whether to log a warning.
This likely will be done for all relevant core k6 blocking calls, but extensions writers can choose what to do.
Warning "fatigue"
It will be nice if users don't see 1 warning per each execution but just per each original call. As it will also not be nice if they don't see all occurrences of this. Especially while transitioning, and they have 10 synchronous calls and 1 asynchronous one.
This can likely be done with some helper function
common.WarnOnce(logger, msg, idKey)
Time will likely fix this
As mentioned before this is a problem mostly due to k6 having only synchronous calls for years. Over time users will stop use them as the new asynchronous ones become more popular and versatile. We also are likely to deprecated all the old ones and have warnings in the documentation against usage.
This still let users mistakenly using synchronous APIs. Also, there will likely be more than a year before most people use asynchronous APIs instead of synchronous ones even if we do more of #2825 type of changes instead of whole API redesigns, which take way longer.
The text was updated successfully, but these errors were encountered:
General description
K6 has historically had only synchronous calls as it also did not have an event loop in order for asynchronous calls to be implemented.
This is no longer the case:
Unfortunately mixing synchronous calls with asynchronous ones leads to blocking the event loop effectively slowing down the execution of asynchronous ones.
Old users will likely have particular problems as they might want to start using a single asynchronous API call. But it will seem to work badly if there are also a bunch of synchronous calls blocking the event loop, delaying the return of a result and potentially making the test fail due to it.
A good example of this happening was already reported, with
sleep
.Solution
During discussions about (in early December) #2728 and the #2863 it was discussed if we can warn users when they call synchronous calls in async functions. This obviously depends on us being able to detect that we are currently in async function at all.
At the time it wasn't certain if that will be possible and later, as #2863 was not merged, work on this stalled, and I never even started working on possible solution.
Currently, it seems like goja does provide us a way to know we are in an asynchronous context. But even without it in practice the moment the first call in the event loop is over - any consequent call is within an asynchronous context, by definition as it need to originate from an asynchronous operation.
Problems:
Scope:
I would argue there should be a way to detect whether we are in async context by a JS module, and then it can decide whether to log a warning.
This likely will be done for all relevant core k6 blocking calls, but extensions writers can choose what to do.
Warning "fatigue"
It will be nice if users don't see 1 warning per each execution but just per each original call. As it will also not be nice if they don't see all occurrences of this. Especially while transitioning, and they have 10 synchronous calls and 1 asynchronous one.
This can likely be done with some helper function
Time will likely fix this
As mentioned before this is a problem mostly due to k6 having only synchronous calls for years. Over time users will stop use them as the new asynchronous ones become more popular and versatile. We also are likely to deprecated all the old ones and have warnings in the documentation against usage.
This still let users mistakenly using synchronous APIs. Also, there will likely be more than a year before most people use asynchronous APIs instead of synchronous ones even if we do more of #2825 type of changes instead of whole API redesigns, which take way longer.
The text was updated successfully, but these errors were encountered: