Allow for configurable connection lifetime

[vishalkuo]

Feature Description

We are in a situation where we don't necessarily want to respect a server's Keep-Alive headers (as they've been configured with a client in mind that isn't 1000s of loadtesting vus) but we don't want to recreate a connection per request as --no-connection-reuse would have us do. Ideally, we'd have an option that'd let us configure a maxConnectionLifetime which would hold a connection open for the min(keepAliveTime, maxConnectionLifetime) and reset the connection at that point.

Suggested Solution (optional)

I imagine we can implement a flag, --max-connection-lifetime that would take a time range string and then use similar to here to control that lifetime, something like

if timerExpired() {
	restartTimer()	
	u.Transport.CloseIdleConnections()	
}

[na--]

Hmm besides noConnectionReuse, we also have noVUConnectionReuse, which will allow keep-alive connections inside of a single iteration, but close them at its end: https://github.com/k6io/k6/blob/0e1f44192f799005f77c5eabe5ba84a6b724ef83/js/runner.go#L731-L733

This seems a bit more predictable than a timer-based approach, since iterations usually model a discrete (part of a) journey in some scenario. Not sure how this applies to your use case, but in general, closing existing connections at the end of an iteration makes logical sense to me.

First, because you know that the connections aren't actively used anymore (CloseIdleConnections() won't affect used connections, if your timer fires mid-iteration). And, maybe more importantly, you wouldn't cause measurement spikes in the middle of an iteration. If your timer expired mid-iteration, you might skew your measurements while subsequent requests had to re-initialize network connections to the server.

And if an iteration is too short of a time-frame (i.e. you want to make more requests before you close your connections), you can always use a for loop (and maybe a group()) inside the iteration function to do that... Not pretty, but it should work 😅

[vishalkuo]

Hmm yeah, we could use this. I think with our current setup, the for loop would have to make ~800 requests... I don't have a good sense of these things but that feels larger than what we want within an iteration. Is that true?

[na--]

An iteration can be a second or an hour, very much depends on your use case, k6 doesn't restrict it 🤷‍♂️ In your case, the iteration_duration metric probably won't be very meaningful, but if you have a group for every loop in the iteration, the group_duration metric can be used as a substitution.

[imiric]

We won't be changing this in the current HTTP API, but it will be possible in the new API (initial design document). We haven't decided on the syntax yet, but will address this once we flesh out the design more.