Forum Discussion
brad_11440
Jan 15, 2009Nimbostratus
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.
- dennypayneEmployeeI have not done a direct comparison but in general the TCP LAN Optimized profile seems to work very well for reducing latency, even for clients not on the LAN (I have used it on applications where the average latency from the client is ~600ms and it still improved response time greatly).
- JRahmAdminIf you're only decisive at layer 4 and below (and you don't need oneconnect), fastL4 is the way to go as it utilizes the Packet Velocity asic on your hardware (though only in assist mode in your case since you're using snat). If you want to optimize http in any way, you'll need the tcp+http profile combination. I've done this with the lan-optimized profile with 20000 connections/second at 300 Mbps traffic on a 3400 (single processor) and CPU never hit 15% and the memory utilization never climbed above 400MB. The 6400 is rated much much higher than that, so unless you are currently really pushing the box, you should be fine with the optimized profile. I would recommend the LAN optimized, even with the WAN environments, it has worked well for me and I've heard the same from other users that it performs better. Your mileage may vary, so test if you can, set up a vip in parallel that you can push X percentage of users to for piloting.
- brad_11440NimbostratusWe are not pushing the box at all right now. CPU and memory utilization are relatively low. I assumed FastL4 would be best since it processes the traffic in hardware. Same reasons switches operate faster than routers (hey, I am a network engineer!). When you say "if you want to optimize http in any way", do you mean for those VIP's where FastL4 is not an option ? Most of our VIPs will be able to use FastL4 but for those that can not we will definitely move to LAN Optimized on both sides. Thanks again. I really hope this makes a difference.
- JRahmAdminyour biggest help will be in the windowing and proxy buffers. To give you a real world, when I replaced a local director with the LTM, the performance dropped across the board, increasing the front page paints by 100% (yes, that bad). first thought was what the heck is wrong with this fancy new gear? Turns out nothing...the local director did nothing to TCP except port mapping and the web servers tcp stacks had been tuned. Well, the LTM is a full proxy, so all that tuning was now gone in reference to the client. Once we tuned the stack on the LTM, not only did performance come back in line across the board, but improved significantly in some areas with no noticable change in LTM performance. If you check the docs section of this site, I've been writing a series on the tcp profile
- smp_86112CirrostratusI was basically in the same position as you about a year ago. By doing a lot of tcp trace analysis, I was able to conclude that basically the LTM was throttling down all of our application traffic - much the same way yours is. It took a lot of studying and analysis, but I eventually came out with a TCP profile that is no longer throttling the connections. From my perspective, here are the most important settings:
- JRahmAdmin"Throttling down" is not a shortcoming in the product, it's really the LTM's tcp stack complying with the configuration in the system. I had a table in my tech tip on windows and buffers (http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=287 Click here) that presents a table that shows the practical max throughput numbers at various window sizes and latencies, and it's really shocking how poor throughput is when latency grows even a little bit, and that's not even taking into account loss. A small congestion window can really hamper a tcp sender's ability to deliver data due to the nature of tcp being a reliable transport protocol, which requires feedback from the receiver before pushing too much data at once.
- smp_86112CirrostratusLTMs are astoundingly robust - I continue to be amazed at how well they perform. I definitely did not mean to imply there were any shortcomings in the product. The throttling was absolutely due to the way we had configured the TCP profile (or more accurately, did not configure the TCP profile).
- JRahmAdminOh, I didn't take it that way at all, just clarifying. Thanks for feedback, and if you have any other product features you'd like me (or one of the other guys) to write a series on, let me know.
- brad_11440NimbostratusThanks for the quick and detailed responses. Still though, I am not sure which one to use (FastL4 or Optimized). We are already moving a single VIP over to FastL4 on Tuesday morning. Doing so will put more of a burden on the physical servers themselves, correct ? That's why I am leaning towards using the optimized profile but obviously I want whatever is fastest and most efficient. Maybe after a week of running on FastL4, I'll see about switching it over to the TCP optimized profile to compare the results.... Thanks once again !
- smp_86112CirrostratusCitizen will probably give you a better answer than this. But if it were me, I would ask myself whether or not I need the LTM to do any manipulation of the traffic. For example if this were an HTTP application, would I need to use iRules to read the URI or headers? If the LTM doesn't need to look this high into the packet, then I'd use a FastL4.
Recent Discussions
Related Content
Â
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects