Forum Discussion

brad_11440's avatar
brad_11440
Icon for Nimbostratus rankNimbostratus
Jan 15, 2009

FastL4 vs Optimized TCP Profiles

We run active/standby 6400 (platform D63a) LTM's for our production applications. They are accessed via clients on a private network with an average latency around 80ms. Nearly all of our virtual servers are using the default standard TCP profile (nagle's, bandwidth delay, low send/receive windows and proxy buffers). We've recently implemented an end-to-end response time analysis solution and have observed very high server response times for those applications that utilize the LTM.

 

 

We want to improve performance and obviously switching to either FastL4 or TCP LAN Optimized profile would do just that. But which one would be better ? I think taking advantage of the two TCP stacks would be a benefit but I am concerned with the increased CPU/memory utilization this would cause. FastL4 would put more burden on the server itself and I am not sure if that is a good thing or not. For the most part, we do not use any extensive iRules (only a simple SNAT rule), so both would be an option. Has anyone done a comparison between the two ?

 

 

Any tips are appreciated. Thanks in advance!
  • Maybe it's about the right time to have you post your VIP config from the bigip.conf. It's possible you have other settings applied to the VIP which conflict with a FastL4 profile??? Also it might be helpful to paste the values of the TCP profile you have applied.

     

     

    Regarding the window size...the behavior you see was bothering me for a long time until it finally clicked in my brain. Yes, the TCP window size always starts at 4380. The trick is to understand whether the LTM is sending or receiving data. When the LTM is sending data, as in this case, there is no need for the LTM to increase its receive window - which is the parameter you refer to in the trace.

     

     

    When the LTM is receiving large amounts of data and you do a trace, you'll see that the LTM receive window starts out at 4380, and quickly increases to the value of the Receive Window as specified in the TCP profile that is applied.

     

     

    The LTM is smart - it starts out with a small window size so it does not need to allocate more memory than necessary for the TCP connection. If it needs to adjust the receive window (when it is receiving data), you'll see it go up.
  • If the only change between the two is the profile (fastL4 or optimized) I don't see why it wouldn't work. I'd open a case with support if you want to pursue the fastL4 option.