Implementing TCP Lan Optimized Profile.

You can look in this thread (Click here) for some further discussion about this. As I stated in that post, most customers I have seen that use the LAN Optimized profile see an increase in speed of their application.

 

 

Tuning the tcp stack in the servers so that they match should result in even better results, I would think. It's hard to say what the results will be given that each environment is different (and that is why there are so many options). You can use OneConnect at the same time, and it should also improve server response time. Again, all of this depends on the app and the environment though.

 

 

Denny

If you don't think your environment has any real unique requirements, I would recommend you do make the two changes you noted. citizen_elah wrote a great article (this is one of a series) on the TCP profile window settings and provided a table for theoretical throughput based on different window sizes (Click here)

 

 

I have made many adjustments to the TCP profile applied to one 6400 9.3.1HF3 LTM pair hosting over 600 VIPs, and at times pushing close to 600Mb/s. I have not seen any significant change in active connections, memory or CPU utilization on the LTMs, or on the back end servers. What I have seen is a drastic improvement in application response, especially for bulk data transfers.

 

 

If you do implement the optimized TCP profiles, I would also recommend trying to disable Slow Start and the Nagle Algorithm. Disabling Slow Start had a huge positive effect on our bulk data transfers. Be advised though that there may be specific scenarios where disabling these values might cause problems - I have only seen one instance where every 10th packet or so on a satellite link was being discarded after disabling Slow Start. But this is the only case - every other instance so far has been hugely positive.

 

 

You can apply a OneConnect profile to a virtual server as long as it also has an HTTP profile applied. OneConnect will maintain TCP connections with your back-end servers, instead of opening a new TCP session for each client. We thought about implementing this for a while, but it had downsides that we couldn't deal with. First, OneConnect uses the source IP address which initiated the TCP connection for all subsequent packet transfers. So in our web logs, we could not distinguish clients based on the source IP address without doing something fancy. And though we never tested this, I believe there would be some problems with Cookie-based persistence.

First, OneConnect uses the source IP address which initiated the TCP connection for all subsequent packet transfers. So in our web logs, we could not distinguish clients based on the source IP address without doing something fancy. And though we never tested this, I believe there would be some problems with Cookie-based persistence.

 

 

 

Maybe I completely misunderstood this.. but, it sounds like your web logs are probably showing the self IP of the LTM, not of the actual source (being the client). You can easily get around this by using the X-Forwarded-For HTTP header. Configure your webserver to use this header in it's logging mechanism... If you are using Apache, no extra modules are needed:

 

 

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"%Du" combined

 

 

Then, make sure the "X-Forwarded-For" header is enabled in your HTTP profile. After this, you should see the real source IPs in your web logs.

 

 

Josh