Re: TCP Window Size
- From: "Thrill5" <nospam@xxxxxxxxxxxxx>
- Date: Thu, 31 May 2007 12:57:28 -0400
Thin clients do not send large amounts of data between the thin client and
terminal server, so window size wouldn't be the problem. My bet is that the
problem is the Terminal Server. 200 clients on a single Terminal Server is
a lot even for non-database type applications. Are you also monitoring the
performance of the TS? You need to monitor memory usage, CPU, disk I/O and
network I/O, active clients, etc. Even if this is a big multi-cpu TS, you
probably have a some type of I/O bottleneck on the server.
Scott
"Trendkill" <jpmason@xxxxxxxxx> wrote in message
news:1180616216.191691.66160@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On May 31, 8:45 am, Cheema <atif_che...@xxxxxxxxx> wrote:
Hi
I would like to share my experience. We have a data base application
with record of 30 million people.
PROBLEM : Slow application access from time to time
Server : data base application
WAN : 12Mbps of clear pipe end to end WAN links
client : A Thin and Terminal Server serving 200 thin/terminal server
clients
Util% : WAN links are max 60% loaded
RTT : 20-120 msec with average RTT of 58msec
Server TCP Window Size : 24kByte
Client TCP Window Size : 65kByte
I have strong understanding that this is due to the SENDER and
RECIEVER capacity mismatch
Kindly advise on this situation
What TCP window size should be used ?
Should it be changed on both ends ?
can FAST TCP be applied in this scenario ?
Waiting for your valuable answer
Thanks
Just from my experience, I have a hard time blaming TCP windowing.
How many concurrent users? Is this real time? How do the queries
look? Are they efficient? What kind of bandwidth per user or per
transaction, and how many users/transactions at any given time?
12Mbps is not that fast, but you need to provide context of whether or
not 12Mbps is enough. Could be anything from server being busy with
backups or some kind of schedule, to WAN pipe utilization going over
80% which would start to impact latency, to service provider, to
anything. Have you used MRTG or Netflow to gauge bandwidth
utilization at these times? How about latency? Do you have a
baseline of these usages and performance during 'good performance'
times? Do you have QoS? Could someone be running a FTP and killing
your pipe?
I won't say that packet/frame sizes are NOT the issue, but I just hate
to look at fundamental networking architecture when there are WAY too
many other variables that are more likely. Not to mention, window
sizes fluctuate, and if this is small telnet or shell based
application, they will most likely never get to full size.
.
- References:
- TCP Window Size
- From: Cheema
- Re: TCP Window Size
- From: Trendkill
- TCP Window Size
- Prev by Date: Re: NTP Server(s)
- Next by Date: Re: Question about big Gig E rings
- Previous by thread: Re: TCP Window Size
- Next by thread: Question about big Gig E rings
- Index(es):
Relevant Pages
|
