Forum Discussion

Randy_Johnson_1's avatar
Randy_Johnson_1
Icon for Nimbostratus rankNimbostratus
Dec 28, 2009

Big IP 'retry' behavior and iRules ?

We have an application that has a limited number of 'slots' available for servicing requests.

 

This usually occurs very quickly, and we have multiple pool members with a load balancing algorhithm of 'Least Connections(node)'.

 

 

However, we've recently begun to have concern that these queus are not being serviced quickly enough and that connections may be waiting.

 

 

What is the Load balancer behavior in a case like this ? Does it merely dispatch a requerst to the server with the least connections (regardless of how many connections it may have), and if the server is unable to process the request in a timely fashion, is the request dropped and forgotten ?

 

 

Is there some way to detect this type of behavior with an iRule ?

 

 

Thanks !!
application delivery
dev
devops
iRules
  • The_Bhattman's avatar
    The_Bhattman
    Icon for Nimbostratus rankNimbostratus
    Dec 29, 2009
    Hi Randy,

     

    THe load balancing decisions should be in the microseconds.

     

    If you set it to Least Connections (nodes). It basically tracks all connections between the client and node as so long as the communication goes through the LTM. However, it cannot account for any connections within the same segment. The LTM is suppose to track this in realtime at line speed.

     

     

    The best way to see this action is a through a packet capture and measure the speed of the packets to see if it's processing fast enough for your application.

     

     

    I hope that helps

     

     

    Bhattman
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Dec 29, 2009
    In addition to Bhattman's comments here are a few more responses:

     

     

    Does it merely dispatch a request to the server with the least connections (regardless of how many connections it may have)...

     

     

    As Bhattman said, yes. The load balancing decision is made based on the number of current connections to each pool member.

     

     

    ...and if the server is unable to process the request in a timely fashion, is the request dropped and forgotten?

     

     

     

    If the pool member accepts the TCP connection, but does not send any data, LTM will close the client and server TCP connection after the idle timeout configured in the TCP or FastL4 profile expires. If the pool member does not accept the TCP connection, the LB_FAILED iRule event would be triggered and by default the client connection would be closed.

     

     

    Is there some way to detect this type of behavior with an iRule?

     

     

     

    In v10 or higher, you could potentially use the after command (Click here) with a timer just lower than the TCP profile idle timeout (retrieved using PROFILE::tcp idle_timeout Click here) to check for connections that are just about to be timed out. I'm not sure how efficient this would be though. So try testing it on a dev unit first.

     

     

    Thanks,

     

    Aaron