Ability to use output of previous attack for a new attack

[spier]

Assuming I run an attack like this:

vegeta attack -duration=10s -rate=2 -targets=targets.txt > results.vr

It would be great if I could given results.vr to somebody and tell them to run it again like:

vegeta attack -playback=results.vr

This would then run the attack exactly the way that it was run the first time.

This assumes that all parameters used for the 1st attack could be persisted within results.vr somehow, including all URLs used. This would also be helpful in order to display the attack parameters in the different report forms, in order to distinguish different attacks from each other.

[tsenart]

Instead of conflating the intent of functionality of the attack command output, why don't you just send the targets.txt file along with the command to whoever wants to run it again? If it's a single URL it becomes easier!

echo "GET http://localhost:999" | vegeta attack -duration=10s -rate=2 | vegeta report

If the problem is missing information in the reports, please let me know what exactly you are missing.

[spier]

Damn you are fast with the replies :)

I was thinking of this scenario:
I have a targets.txt file with 100 URLs. Now I run an attack for 10s with 2 calls/second, so I just use 20 URLs in total. If I have used -ordering=random, then I don't know which URLs were used, meaning it is hard to repeat the exact same attack.

As for missing information in the output:
After the facts I don't know the duration, the rate, and the URLs that were attacked.

[tsenart]

As to the first paragraph, you can use -ordering=sequential to solve your determinism problem.
On the missing information in the text report, by adding the duration which is indeed now missing, you can know the rate as the number of requests is already there.
On the URLs, Vegeta was built with the purpose of hitting homogenous sets of URLs per attack, all belonging to the same logical endpoint. If you mix and match different endpoints, your results are not going to be statistically representative.

[spier]

I understand the purpose that you are describing.

vegeta can be used for other scenarios as well though. e.g. I am simulating the behaviour of one mobile client. That client might fire different API calls in different order. Therefore the response time of every individual requests matters as much as the overall experience of the user. With that purpose in mind, I have indeed used target files that contain API calls for different endpoints.

Either way, it is definitely possible to work around this issue by creating different sets of target files. Just though it might be an interesting idea to explore.