Firstly, great work on Artillery.
Secondly, there doesn't seem to be a way to simulate asynchronous requests. E.g. our React app makes 5 asynchronous calls after initialisation that don't depend on each other and we of course wish to simulate this real-world scenario for each virtual user.
Therefore something like...
scenarios:
- name: "My Scenario"
flow:
- get:
url: "/profile/basic"
async: true
- get:
url: "/transactions/recent/{{ accoundId }}"
async: true
- get:
url: "/transactions/pending/{{ accoundId }}"
async: true
- get:
url: "/accountsummary/{{ accoundId }}"
async: true
or
scenarios:
- name: "My Scenario"
flow:
- async:
- get:
url: "/profile/basic"
- get:
url: "/transactions/recent/{{ accoundId }}"
- get:
url: "/transactions/pending/{{ accoundId }}"
- get:
url: "/accountsummary/{{ accoundId }}"
I appreciate there is then this issue of one async call depending on the result of another async call, so perhaps...
scenarios:
- name: "My Scenario"
flow:
- get:
id: "profile"
url: "/profile/basic"
async: true
- get:
waitFor: "profile"
url: "/transactions/recent/{{ accoundId }}"
capture:
json: "$.id"
as: "id"
Happy to contribute.
This is something that has been asked for before (e.g. https://github.com/shoreditch-ops/artillery/issues/164). Thinking about it now, I think I would prefer having an async block rather than marking individual requests as async. The entire async block should be treated as a step, i.e. the flow does not progress on to the next action until all async requests are completed. Introducing dependencies between async calls is an overkill IMO - if one request depends on the response of another, it should simply follow it in the flow. Of course I appreciate that it might not work for every scenario, but I'm not sure the tradeoff between complexity and making a scenario more realistic would be worth it at this point.
Thanks @hassy. Cool, yeah, that makes absolute sense.
I think an async block (treated essentially as a Promise.all()) with the ability to capture results for the next step as normal, covers all cases I can imagine.
Is it worth me attempting to contribute or something you wish to add to your own roadmap?
Implemented and will be available in the next release of Artillery.
Most helpful comment
This is something that has been asked for before (e.g. https://github.com/shoreditch-ops/artillery/issues/164). Thinking about it now, I think I would prefer having an
asyncblock rather than marking individual requests asasync. The entireasyncblock should be treated as a step, i.e. the flow does not progress on to the next action until all async requests are completed. Introducing dependencies between async calls is an overkill IMO - if one request depends on the response of another, it should simply follow it in the flow. Of course I appreciate that it might not work for every scenario, but I'm not sure the tradeoff between complexity and making a scenario more realistic would be worth it at this point.