Injecting latency into application requests?

@dubdub - Yep, you sure could. That would be trusting the javascript and putting the delay on the client, however, meaning you'd be responding from the LTM, trusting the client to hang around and wait, and then re-send a new request after a certain delay. While that would work in many situations, it isn't the same as far as the client is concerned as just inducing delay at the network layer.

@nitass - That is an excellent question, and something I'm going to be documenting in much more detail in a tech tip either this week or next, but the short version is: suspend commands allow OTHER connections to continue processing, I believe I mis-spoke earlier on that, while a blocking command ties up a TMM and makes it sit there waiting for that particular command to finish before it can continue processing anything.

I.E. if I do an after, my connection's iRule is suspended, but other traffic continues processing just fine. If I put myself into a loop or run an open collect, that TMM is now busy until the command returns, and will be unable to process any other traffic until that time.

That does raise a good question though: Will the after command itself add latency to a connection if you want it to? The more I think about it, yes I suppose it could. I'm just used to thinking of blocking commands as the delay inducing bunch, not the suspending commands since processing continues despite a command suspension.

Something like:

when HTTP_REQUEST {
  after 3000 {
    pool myPool
  }
}

applied to a VIP with no default pool could induce such a delay I suppose. I'll have to poke at that and test it to be sure, but that makes sense.

Colin