Adds Load Testing for:

• No-Operation Requests
• Signing
• Verification
• Verification through a web server
• End-to-end test (sends a request to the signatory for signing, returns the signed message to the client, sends the signed message to the web server, the web server forward the message to the to verifier, the verifier returns the verification response to the web server, and the web server forwards the verification response to the client)

Implementation (using a signing request test as an example):

• A signatory is started, and set up to listen at port 3000
• Two signing requests are sent to the signatory concurrently, in separate go routines. These two requests are referred to as a "batch" of requests
• The percent of the requests in this batch that succeed is recorded, and then another batch of the same size is sent.
• This process is repeated until 10 batches of size 2 have been sent
• After 10 batches, the batch size is doubled (to 4 concurrent requests), and the process repeats
• For each batch size, 10 batches are run, then the size of the batches is doubled
• This continues until the percent of successful operations in one of the batches falls below 50%

Once load testing completes a histogram is created and saved, displaying:

• The percent of successful operations per batch
• The number of concurrent requests the operation was able to handle before experiencing a failure rate > 50%

The number of concurrent operations the system can handle is dependent on the timeout allowed for each operation. The longer the timeout, the more concurrent requests can be successfully handled. The load testing process above is run for each of a number of different timeouts for each operation, and generates a histogram for each timeout. The default timeouts, as of now, are 10ms, 100ms, and 1s. (So, for each of the 5 operation types, 3 timeouts are run, generating 3 histograms, for a total of 15 histograms.)

A signatory, verifier, and web server must be run during testing to support the full range of load test types.

No-Op
Support for no-operation requests is added to the local signatory implementation. No-Op requests can be trigger by sending a signature request with the string "dryrun" in place of the url.

Retries
Retries are run on the first group of 10 batches (containing 2 requests per batch) to account for the expected initial failures caused by a lack of a dns record. If a failure percent below 50% is observed in this first group, the group is rerun, up to a max of 20 retries. Retries of this group are inexpensive, as each batch contains only 2 requests. All other groups are run only once.