Ira Abramov wrote:
I don't know about "normal". After all, as Suzan Saradon so aptly put it, what is normal anyways? I will say that it makes sense, though, on some level. It is totally bewildering on others.howdie people,
I just upgraded my server from a Pentium III 500 to a P4 2.8G. I noticed that even though web traffic hasn't changed or even increasedm the netstat behaves differently, specific I have considerably less connections live at any moment, but the ones I do have are mostly at the "syn recieved" stage rather than "connected".
http://jenna.scso.com/hotsanic/netstat/connections-month.gif
this stat by hotsanic and rrdtool shows the sharp change a week ago when I did the switch. the kernel is the same 2.6.8 from Debian Sarge.
Does it seem normal? both me and the other website users see the same
performance if not better naturally.
Thanks, Ira.
I'll just mention that the measurement that is really of interest to you is web site access latency. This is what the user sees, and is annoyed by.
Assuming the latency is the same or better after the move. It may actually mean that your server was bottlenecked before, and you have managed to shift the bottleneck to the network latency. Good move if that's true.
"SYN Received" means that a socket that was in "LISTEN" received a SYN, and sent out a SYN+ACK. It is now waiting for a final ACK before it switches over to "ESTABLISHED". Once in "ESTABLISHED", it will serve the data out, and then (depending on the HTTP mode used and the server configuration) either send out a FIN (which will put it in FINWAIT1), or receive a FIN (which will technically put it into CLOSEWAIT, but as Apache will immediately close it's side of the connection, this will actually be LASTACK) If the former is what happens, once an ACK is received you will get "FINWAIT2" until a FIN is received from the other side. If the second, once an ACK is received, the socket will simply be closed and should disappear fairly immediately. The full state diagram is in RFC 793.
To me, the change in network behavior seems to indicate that there is a decrease in host-based latencies, and an increase in network-based latencies. Before week 53, we have had a fixed amount of "listen" (makes sense - a listening socket does not disappear once a connection is established, so this much makes sense), a varying amount of connections in "ESTABLISHED" (meaning either data is moving back and forth, or the connection hangs around in case the browser wants it for something more), some FIN2 (i.e. - we closed the connection, but the client has not done so yet), and lots of "time wait" (i.e. - the connection is already closed, but some TCP/IP semantics mean we cannot forget about it yet).
The first significant change happens during the beginning of week 53. Someone lowered the simultanious amount of Apache listening sockets. This can have one of two possible explanations. Either someone changed the apache config to keep less open sockets or less concurrent processes, or apache, of it's own accord, came to the conclusion it can make do with less. You tell us which.
The second change happens torward the end of the same week. All of a sudden, there are very little established connections, and lots and lots of syn-recvd connections. At the same time, there is a sharp decrease in the amount of "time wait" connections, but no change in the "closing" (a.k.a "simultanious FIN") connections. Again, SYN-recvd is a network latency state - we are waiting for an ACK on our SYN+ACK. Time-wait is almost unavoidable, but is a function of the number of simultanious connections.
One possible explanation is that someone changed the "persistent" option for Apache. This option means that each TCP connection only handles one HTTP request and then closes. I am not sure whether this means "on" or "off". It depends on your site's usage characteristics.
So, points to ponder:
1. Was there any change in configuration besides the cpu switch?
Apache options etc?
2. What happened at the beginning of week 53?
3. Was there some change in network latency that is unrelated to your
specific computer?A faster machine may result in actual pages being served faster, which in turn results in spending less time in "ESTABLISHED" mode. A reduction in "TIME WAIT" may mean that persistent connections was turned on, and the browsers now shut down the connection on their own accord when they no longer have data to transfer. When the shutdown is the browser's idea, the server will not enter "TIMEWAIT".
The increase in SYN-RECV, however, is rather inexplicable to me. I can't think of what would cause such a sharp rise, unless some horribly broken firewall somewhere (have seen such things in the past, though).
Shachar
-- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
