Injecting latency into application requests?

is after command usable?

 

 

after wiki

 

http://devcentral.f5.com/wiki/iRules.after.ashx

 

 

v.10 - iRules and the after command by Colin

 

http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/348/v10--iRules-and-the-after-command.aspx

You might be able to call HTTP::collect to hold the request and then use after to call HTTP::release to release the request.

 

 

http://devcentral.f5.com/wiki/iRules.http__collect.ashx

 

http://devcentral.f5.com/wiki/iRules.http__release.ashx

 

 

Aaron

It is definitely possible, the problem is that, depending on how you end up writing the rule, you may be delaying all traffic going through the box by that amount. It's important to avoid loops and blocking commands if you only want to degrade traffic bound for a particular VIP. A collect, as Aaron mentioned, is probably the safest way to suspend a single connection, just be wary of the performance implications of this.

 

 

Colin

Hi Aaron/Colin,

 

 

Just wonder what is purpose of calling HTTP::collect before using after. May we only use after?

 

 

Thanks!

I think you'd want to call HTTP::collect with no collection size to hold the connection and then use 'after' to call HTTP::release. This is similar in concept to using HTTP::collect to hold the current request while you perform OCSP or other authentication.

 

 

I'm not sure how you could use 'after' by itself to stop the request from being sent to the pool or otherwise add latency. I could certainly be missing something on this though :)

 

 

Aaron

thanks Aaron!

The after command is non blocking. It will fire and allow the connection to continue processing as normal, so there would be no inherent latency. That is, in fact, the entire purpose of the after command: to allow you to continue processing a session while assigning some task to be done at a specified time. To actually pause the connection and add latency, you need to do something that will suspend things, like a collect, a loop, etc. A collect is likely the safest means is all.

 

 

I still want to make sure everyone knows this practice is generally a very bad thing, as it can slow things down that you aren't expecting...but there you have it. ;)

 

 

Colin

Another thought: could you inject a javascript delay function with a stream profile/expression? Change the body tag to include a javascript snippet that just spins CPU cycles for a bit? http://stackoverflow.com/questions/951021/javascript-sleep

The after command is non blocking.you mean after is suspend command but it is non blocking. what is different between suspend and blocking??

 

 

sol12962: Some iRules commands temporarily suspend iRule processing

 

http://support.f5.com/kb/en-us/solutions/public/12000/900/sol12962

@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