Real Least Connections iRule

Hi Chad,

if you skip the

timeout

and

lifetimes

parameters on the

[table]

command, it will default to a 180 second timeout with indef lifetime. And once the

[table]

data begins to timeout, the entire iRule will more or less produce unpredictable results. To counter the timeout problematic, you may want to either use long lasting timeouts again, or initialize some

after X_msec -periodic { set x [table lookup xyz] }

handlers during the

SERVER_CONNECTED

event to to refresh the counters of the individual

[table]

records right before they will timeout).

Note: The

[LB::reselect]

command allows just a single reselection during the

LB_SELECTED

event(its an undocumented behavior). So if the pool contains a couple or even more nodes, the chances to get an equal balancing with this iRule is rather small. E.g. if

[active_members [LB::server pool]]

=

10

and

[table keys -subtable XYZ -count]

=

9

it will result in a ~10% chance to

LB::reselect

the node which currently has the fewest connections. If a wrong

LB::reselect

happens the highconn

[table]

value is in addition not increased, causing the the

SERVER_CONNECTED

event to overwrite existing

[table -subtable]

data, which will in the end cause uncounted connections and may lead to a uneven distribution.

Note2: In addition you may try to store the result of a

[table]

call into a variable and reuse this data as much as possible. The reason for that is, that each

[table]

call will cause a TMM parking situation and therefor slows down the iRule execution pretty much. Some code blocks call the same

[table]

commands over and over without any reason...

Cheers, Kai