Open akira opened 9 years ago
Upon initial inspection of vegeta, the -targets
flag to the attack
command currently supports all of this. The way we use it today is the default of providing a single target, in the form of GET scheme://domain:port/path
, via stdin. However, the argument to the -targets
flag is expected to be a file on disk. The contents of which should be a line separated description of the request, optionally including specific request headers and body.
We could start accepting a couple of new options in the ProjectConfiguration:
method
: GET/POST/PUT/DELETE/etc.headers
: {} *this already existsbody
If we look at our current invocation from the HttpLoadTester, we create a new instance of the VegetaDrive for every endpoint configured. When/where should we write this file for the -targets
flag? Should we rework the HttpLoadTester to just provide all endpoints
to the VegetaDriver and handle things there?
:+1: to the ProjectConfiguration options.
For Vegeta, might be easier to still keep it the same flow as now (single target per run), but just create the target file for the single endpoint? We would also need to use a -body
file as well if that's present?
In this case, I think we'll build one file per endpoint in the VegetaDriver. That file will include the request method, URI, headers, and body of the request. We should clean up the file after.
I consider this "Highest-ROI work" at the moment, so I'll mark this as P1 for now.
As a perfci user, I should be able to create endpoints that are PUT / POST / DELETE with options to specify headers and request boy.
Acceptance Criteria
Use case
Sub-tasks