About the parallel processing of iRules

Do you want rule-A to loop constantly until an event happens in rule-B on a different virtual server? I think technically, you could do this using a global variable which both rules reference. I have no idea what impact this would have on TMM though. Are you able to test this? If so, can you post the rules you're using?

 

 

Aaron

Thank you for the answer.

 

iRules-A and iRules-B are as follows.

 

 

 

＜iRules-A＞

 

when CLIENT_ACCEPTED {

 

set ::flg 0

 

while {$::flg == 0} {

 

}

 

}

 

 

 

＜iRules-B＞

 

when CLIENT_ACCEPTED {

 

set ::flg 1

 

}

 

 

 

I would appreciate your favor.

 

 

In general, having a tight loop such as in iRule-A (without sleep calls) is probably not a great idea. For my own curiosity, I did a quick experiment and it looks like it grinds TMOS to a halt until eventally it timesout which took a long time (on 9.2.5). This is a bit scary as a badly written iRule could easily bring the whole Big-IP down.

 

 

It might be a good enhancement to the iRule engine to more aggresively prevent runaway iRules like this by capping execution cycles.

 

 

Also, it looks like tcl commands "after" and "vwait" are both disabled for iRule so there isn't a way to do any kind of "sleep", so there isn't a way to wait with a lesser impact.

 

 

But to answer the more general question, indeed iRule executions have to be in parallel or else the performance would be horrible with many concurrent requests. Are you just trying to verify parrallel execution or do you have a specific scenario in mind?

 

 

//Joe

 

Thank you for the answer.

 

 

I am building the system which verifies bandwidth control.

 

(It is not actual operation but "verification".)

 

 

And the following scenarios are considered.

 

1. When a certain communication comes to BIG-IP, make the communication once stand by. (Above-mentioned iRules-A)

 

 

2. obtaining a communicative check and control of a bandwidth by an application server -- 。

 

 

3. When processing by an application server is completed, make communication resume. (Above-mentioned iRules-B)

 

Are you looking to verify that you've configured the F5 device correctly such that it is effectively controlling the bandwidth? If so, I think the virtual server statistics (and pool stats) may give you enough data to calculate actual bandwidth. Specifically, client bytes in and out and server bytes in and out.

 

 

Or did you implement some for of bandwidth control in your application server itself and you want to verify whether that is working correctly? I think that that case as long as all traffic is going through the same virtual server and pool, the same stats would give you the data you need.

 

 

If that is not what you're trying to do, maybe you can clarify?

 

 

//Joe

Thank you for the answer.

 

 

I am going to make the application server instead of BIG-IP do control of a bandwidth.

 

The information on the communication which came by BIG-IP from the client is notified to an application server.

 

A suitable bandwidth is secured from the information on the notified communication in an application server.

 

When reservation of a bandwidth is successful, the communication made to stand by is resumed.

 

When reservation of a bandwidth goes wrong, the communication made to stand by is refused.

 

Sounds llike you want the application server to decide what bandwidth reservation is granted but you want to use an iRule on the BIG-IP to actually grant or reject the request? Is it really a bandwidth reservation or do you just want to dynamically enable and disable incoming requests at the BIG-IP?

 

 

Using an iRule on another virtual server to throttle incoming requests is an interesting use of iRules. 8-) I can see the following working, using only 1 iRule.

 

 

when HTTP_REQUEST {

 

 

if { ([HTTP::path] ends_with "StoreEndUser") } {

 

 

}

 

 

//Joe

Oops - posted prematurely. The iRule could be something like the following:

 

 

when HTTP_REQUEST {

 

 

if { ([HTTP::path] ends_with "stop") } {

 

set ::allow 0

 

}

 

elseif { ([HTTP::path] ends_with "go") } {

 

set ::allow 1

 

}

 

else {

 

if { ($::allow == 0) } {

 

HTTP::redirect http://somewhereelse.com

 

}

 

}

 

}

 

 

Then the app server when send a http request to the same virtual server with the path ending with "stop" or "go" to control the flow.

 

 

I would recommend that you use iControl to do this though as iControl is meant to give you programmtic control of virtual servers. However, your approach is certainly interesting. 8-)

 

 

//Joe

 

Thank you for the answer.

 

 

Yes, I want the application server to decide what bandwidth reservation is granted but I want to use an iRule on the BIG-IP to actually grant or reject the request.

 

 

Instantly, it tried.

 

However, while carrying out loop processing by other VirtualServer(VirtualServerA), the above-mentioned HTTP_REQUEST(VirtualServerB) event does not move.

 

When loop processing is completed, a HTTP_REQUEST event moves.

 

 

While carrying out loop processing, Doesn't iRules move simultaneously?

 

I would eliminate the loop altogether. If I understand what you're trying to accomplish, you simply need to set a global var to either allow incoming traffic to flow to the application server or to reject or redirect incoming traffic. You should not wait for the application server to decide for each request at request time and wait for that answer. In otherwords, just check the flag and reject traffic or alllow traffic depending on the state of the flag.

 

 

And to change the state of the flag, the code on your application server should make an http request to the same virtual server with two different URLs (e.g. http:///bandwidthcontrol_go and http:///bandwidthcontrol_stop) which will toggle the flag by triggering the appropriate section in the iRule.

 

 

Hope this does what you need. Again, if your application server can make web services calls, another way is to use iControl to for example enable and disable the node.

 

 

//Joe