Forum Discussion
smp_86112
Cirrostratus
CirrostratusTCP Profile Optimizaiton - Nagle vs Delayed ACKs
In my never-ending quest to reduce the complaints about performance of our HTTP apps hosted by our LTMs, I've been doing a lot of investigation into how to optimize our TCP profile. I ran across an article on the net today about a deadlock situation that can occur between Nagle's algorithm and Delayed Acknowledgements. Both are enabled in our default TCP profile.
I already know that I need to disable Nagle. But after reading the article (http://www.stuartcheshire.org/papers/NagleDelayedAck/) and subsequently others, I am starting to wonder if I shouldn't try disabling both. If I interpret the article correctly, I'm thinking that delays are introduced by Nagle when the LTM is sending HTTP responses, and more delays are introduced by Delayed ACKs when the LTM is receiving data from the client. Obviously both events happen in every HTTP session.
I know in tcpdumps that I've seen the 100ms timer many times. I always attributed this to Nagle. But I never thought to pay more attention to whether the LTM was sending or receiving data when those delays are introduced. Now I'm wondering if I'm seeing the Delayed Acks timer, the Nagle timer, or both.
Does anyone know if both Nagle and Delayed Acks have a 100ms timer built into the LTM TCP stack?
Has anyone ever tweaked their TCP profile to disable both settings? I'd be very interested to learn about your experience.
Thanks.
smp_86112You can disregard this post.
After about 12 hours of reading this weekend, I think I finally understand that my problem is being caused b a combination of two factors: much too small window sizes, and the interaction between Nagle and Delayed Acks. The delay problem is there, but it is made much worse by the window sizes. I am already in the processes of increasing the window sizes to 64K, and I will be disabling the Nagle algorithm too. That should clean this up quite a bit.
hoolioWhen you finish your testing, could you post the final config and your test results? I think it would be helpful for others to see.
Thanks,
Aaron- JRahm
Admin
I've tweaked and tuned and hunted and pecked, and by far the best performing profile for our http applications, LAN or WAN, has been the tcp-lan-optimized profile, applied to both sides of connection. - hoolioHey Citizen,
Out of curiosity, do you have a broad client base connecting from all types of providers? We're about to configure TCP profiles on an HTTPS VIP for a customer who has a very diverse client base.
I was assuming it would be better to use the WAN optimized profile for an application where clients could still be using dialup and generally might not have the best providers.
Thanks for any tips,
Aaron - JRahmgreatest client source is 256k frame access, the rest (less than 10%) lan and DSL. I thought the WAN profile would be ideal too, but our application response times and front-page paints did not bare that out.
- JRahmScratch that...crossed streams there with our termserv environment. Yes, with our http apps, they are internet client facing, so the client base is uncontrolled.
- dennypayne
Employee
Posted By hoolio on 09/02/2008 10:45 AM
I was assuming it would be better to use the WAN optimized profile for an application where clients could still be using dialup and generally might not have the best providers.
I thought this too, but I encountered several situations where clients were coming across different high-latency dedicated links (~300-600ms RTT), and Nagle's was killing the app response time. Used tcp-lan-optimized and problem went away. So I'm with citizen on using the lan-optimized for everything.
Denny - hoolioThanks for the tips guys. I'll let you know what we find as well.
Thanks,
Aaron
