Does Mittens support non-randomized requests?

[erodewald]

I've found that, in order to warm up my service, I need to access the exact pathways. Creating bespoke endpoints for Mittens doesn't really help with my JVM app. Additionally, headers aren't universally applicable in my service.

I'm thinking of the following features:

• an ordered array of requests
• each request can have its own:
  • headers
  • delay interval
  • repeat count

This would solve for scenarios where, for example, you would like to create an entity with an explicit header, and then make subsequent GETs for that value, then follow it up with a clean-up delete operation.

I've seen no such flags that would allow an organized approach. Is this on Mittens' roadmap, or would you take pull requests?

[worldtiki]

Hi @erodewald and thanks for raising this issue 👋

I like the idea of having some sort of order in the requests. It increases the use cases where Mittens can be used, and I think it can be done in a way where it doesn't add complexity to the end user that is using this (ie, it can be an optional flag/parameter).

But I'm a bit reluctant to add the other per-request overrides, specially the delay interval and repeat count. I feel like if we open the door to those features, it would bring Mittens closer to a testing framework to run smoke tests, which is not the intent of this tool.

I'm happy to have a longer discussion about this, but my gut feeling tells me that some of those features are not something that we'd like to have in Mittens.

[nikos912000]

Hi @erodewald, thanks for the request and your contributions!

I think having ordered requests would bring value to the users. The headers per request may also be useful. But anything beyond that I'm afraid would add complexity and would defeat the purpose of the tool. In fact, at some point we did a lot of cleanup and removed flags that wouldn't add value to the majority of the users.

[erodewald]

Thanks for the discussion everyone. I understand the desire to keep this project lean. My organization prefers some blend of the aforementioned features and I would like to lean on / contribute to OSS where feasible.

The most value for us comes from sequential ordering of requests, as opposed to a randomization of the supplied requests. I could certainly live without the extra complexity of per-request delay/repeat.

What do we think about implementation for sequential requests? Perhaps an optional flag --sequential=true(default: false) which would then take the --http-requests flags in the order they appear. Due to the nature of this utility being "run these requests for N seconds", it would be logical to run those requests cyclically. Thoughts?

[nikos912000]

I like the idea, and the implementation sounds sensible. Would you like to give this a try @erodewald?

[worldtiki]

I like it 😊

I wonder if maybe this flag could have slightly different semantics?

Instead of --sequential=true(default: false) maybe --potato=sequential(default: random)?

It would have the same complexity in terms of the implementation and user experience but could be extended in the future. Maybe a 3rd mode where we loopOnce the list of http requests instead of running the requests for N seconds.

That said, I'm happy with the sequential if you prefer that name. And obviously potato is just a placeholder and not the name I'm suggesting :p

[erodewald]

@nikos912000 Would you like to give this a try @erodewald?

I'm not well-versed in Golang but I'd like to give it a shot. I've got resources over here that can help me put something decent forth.

@worldtiki It would have the same complexity in terms of the implementation and user experience but could be extended in the future. Maybe a 3rd mode where we loopOnce the list of http requests instead of running the requests for N seconds.

Great idea, how about --execution-mode=sequential(default: random)? Like you said, it leaves the door open for additional modes.