NetScaler 10: Keep-Alive value add to the TCP stack with profiles

NetScaler 10: Keep-Alive value add to the TCP stack with profiles -

TCP profiles were very helpful and convenient to use for various use cases and deployment scenarios. A few weeks back we discussed TCP profiles and the last blog (/ blogs / 2012/04/26 / NetScaler-10-tune-tcp-stack-for-wireless-use cases-with-Westwood /) focused on setting Westwood Wireless Networks. Latest NetScaler 10 GA build adds a new Keep-Alive feature on the TCP stack and allows NetScaler to probe TCP connections end NetScaler. After image shows the different options available with the Keep-Alive functionality.

In using the case of keep-alive today can be of good help because it allows NetScaler to find proactively whether the client is alive or death while consuming connection resources. After a preconfigured time, NetScaler sends Keep-Alive client probe packets and waits for acknowledgment. In case the packet is dropped or the client does not respond in time, NetScaler can send repeated probes by the configuration. Finally NetScaler can decide to reset the connection if the client repeated probes does not answer back at all. In this way, NetScaler can free resources and use them for other active clients. This is also true for the TCP server side communication, because the same profile can be connected to services as well. Let the parameters:

• probes Keep-alive
  • By default, it is kept off
  • allowing rest of parameters come into action
• Log idle time before sending probes
  • This is the time we expect an idle connection before sending probes
  • by default, we wait for 15 minutes (00 seconds) and you can change it as you like
• Keep-alive probe interval
  • After 15 minutes of inactivity, we send the first probe to
  • What if the client does not respond to the probe or it is lost on the wire
  • we can not end the connection based on just a single probe
  • This parameter allows us to send probes successive after given interval
• probes maximum keep-alive
  • This works with the previous setting
  • the number of probes define the number of successive probes, we have to send
  • Each probe is sent after the interval set with the previous setting
  • If the client responds back after the first probe, then rest of them are not sent
  • Upon receipt of the response of the client, we return to logic 15 minutes of time of inactivity

you must be careful of the probe Keep-Alive interaction with setting timeout on vserver or respective services. If lower idle time, the connection will be rinsed before Keep-Alive logic never goes off the flow. I'm sure given the resources crisis we face on a daily basis, this new feature will help most common deployments ...

Tweet