06-03-2009 08:56 AM
This depends on what is actually happening :-).
A ServerIron is going to declare a real server as failed immediately in case the server is sending an incorrect response back in reply to a layer 7 health check (incorrect means incorrect content or status code depending on the health check configuration).
There are nevertheless cases without any response from the real server at all (NO response at layer 7). The ServerIron is trying to send health check packets to the real servers but there is no L7 response OR the response is coming very late (delayed). The situation is different in this case. You do have to configure health check intervals and the amount of retries in port profiles and as well below the configuration of healthck's and port profiles. The interval is the time in between two health checks going to the same real server. This is as well the timeout of a single health check try - a health check try is getting declared as failed in case the next health check is starting. The ServerIron needs to retry the health check as often as configured to declare a server as down based on no replies or delayed replies. The amount of time before a real server is getting taken out of service is therefore higher in case it is because of slow responses or no responses at all compared to incorrect layer 7 replies.
It wait eat up "interval * (retries + 1)" to declare a server as down talking about the worst-case scenario.