Tuning TCP stack with the "tcp_slow_start_initial" parameter

Tuning TCP stack with the "tcp_slow_start_initial" parameter

Post by James367 » Wed, 25 Jun 2003 05:44:30



Greetings,

I was sent the link below and given the task to research whether we
should implement this in our web environment.  Our primary client is IE,
so it seems like this is worth the effort of regression testing and
possible implementation.

Question, has anyone tweaked their Solaris TCP stack with the
"tcp_slow_start_initial" parameter and identified any resulting
performance change?

This is listed in the Solaris Tunable Parameters manual for the 02/02
release, but is noted as "do not change".  Link:
http://docs.sun.com/db/doc/816-0607?q=tcp_slow_start_initial

TIA for any response,

James Yaple

------

Some of this info is from http://www.pmg.com/tip_archive/01_01.htm

===== From the link

The most widespread critical performance problem with web servers today
involves SUN webservers accessed from Microsoft Clients. If you access
SUN webservers that seem to be slow or operate SUN servers you'll want
to pay special attention to this tip and implement the fix on the SUN
servers immediately!

The problem has to do with TCP stack functions related to TCP slow
start, RFC 2001. SUN and Microsoft contend that they are implementing
the RFC correctly  we call it being "dead right", similar to DMV
commercials referring to those that insist on their "right of way",
while leaving all parties involved dead dead slow that is. Either way,
a change of the SUN default parameters fixes the problem for millions of
Microsoft Client users accessing SUN webservers.

When a web page is opened by a client a TCP connection is spawned
through which the data flows between the client and server. TCP
connections are used by all internet web communications. A web page
consists of a text descriptor and many separate graphic images. First,
the text with page descriptors is loaded, containing a list of the
images required to load. The combination of text and images display the
page in an attractive manner. Each image loaded must spawn its own
separate TCP connection to load the image. The result is that dozens or
even hundreds of TCP connections for each page are shown in your browser.

The problem between Microsoft Clients and SUN web servers (and other
applications with lots of short lived connections) is a delay in sending
the second packet until the first packet has been acknowledged. SUN's
implementation of TCP slowstart is active on the first packet by
default, making the second packet wait for the first packet to be
acknowledged requiring a full round trip delay plus up to 200
milliseconds of potential ack delay (RFC1122) in the Microsoft client
too! So that means that if you are, let's say, 100 milliseconds away
from a server you are accessing on the Internet, up to 300 milliseconds
of delay can occur between the first packet and the second packet of the
initial html text descriptor data. So, with that kind of delay for each
TCP connection, perhaps 20 images on the page up to six seconds of
delay can be attributed to this one default parameter setting on the SUN
web server!