Support more HTTP options for performance tests

[akira]

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

• Endpoint configuration to support options above (I don't believe any work is needed for this).
• Vegeta driver to support options above
• Vegeta docker image to support options above

  Use case

• I would like to use it to test ElasticSearch query behavior - usually ES can have some pretty long queries which go beyond the URL limit.

  Sub-tasks

• [ ] #49 new configuration options
• [ ] cdarwin/vegeta#1 vegeta docker image support for targets file
• [ ] #50 VegetaDriver support for targets file

[cdarwin]

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 exists
• body

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?

[akira]

:+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?

[cdarwin]

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.

[cdarwin]

I consider this "Highest-ROI work" at the moment, so I'll mark this as P1 for now.