Re: Half the speed migrating from Windows 2000 to Windows 2003
- From: redblue <redqil@xxxxxxxxx>
- Date: Wed, 7 May 2008 09:52:56 -0700 (PDT)
On May 7, 4:51 pm, Kesney <Kes...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Is your client and server applications separated by a WAN network or a LAN
network? By using Wireshark network sniffer, you might be able to see how
the slow transmission is being transferred, specially by looking at the
graphics that it creates to analyze the data transfer (number of pakets per
second and number of bytes per second) No body has been able to identify the
root cause of this issue after 5 months of painstaking troubleshooting.
Microsoft was not helpful with this issue even though the issue only manifest
itself on win2k3/win2k8 and not on XP. Do you have an application buffer
size that you fill up in order to write to the wire or transmit it? What is
the size of that buffer size? You might want to increase it to 64k to
identify whether it makes a difference for you. you can contact me directly
if you would like to chat in more details about this issue (kesney at
gmail.com)
"redblue" wrote:
A long time ago I had written a very simple server that uses AcceptEx,
TransmitFile and IOCPs. It works fine on all versions of NT. Today,
out of curiosity, I ran the server on a virgin Windows 2003 Server
(with sp2) machine and was surprised to see that its performance was
less than half that of the same machine running virgin Windows 2000
Server (with sp4). On w2k, my server gives a speed of ~6700 responses
per second (rps) as opposed to ~3000 rps on the W2k3 machine.
The test configuration:
1.6 G Pentium, 1G RAM. 1000BT ethernet.
Each request/response pair is about 100 bytes each. The socket is
closed after each response.
I have not been able to figure out what could be the reason why such a
drastic drop in performance from an OS that is marketed as given
better performance than its predecessor. I would be grateful if
someone knew the answer offhand.
Thanks for all this information. At the very least this confirms that
this is a known problem and that I haven't exhausted some obvious
options.
To answer your questions:
This is all on a LAN with an 8-port DLink gigabit switch.
I used WCAT to simulate the load from two different 2GHz machines to
pound on the 1.6 GHz server.
The server always fills up its buffer before responding with a single
TransmitFile call. Then the socket is recycled in a socket pool.
The buffers are variable sized, allocated from a pool. In this case,
1K buffers were used, of which 100bytes were actually transmitted.
For larger sized transfers, speeds are the same as in W2K, presumably
because the response rate falls below 3000 rps.
All of this suggests an artificial delay for packet response,
something that gets amortized out for large transfers but not for
small packets.
My googling around revealed the existence of a registry entry called
TcpAckFrequency that was introduced in XP/Server 2003. Adjusting it to
'1' did not solve the problem. I didn't expect it since I get high
throughput on Windows XP Pro even with its limitations on
TransmitFile. But this knowledge does suggest that Microsoft has
tinkered deeply with their TCP/IP stack for XP and beyond.
I have never used WireShark, so I'll play around with it and see if I
learn anything more. I'll keep you posted if I find out something. I
can give you the server if you were interested, but I would imagine
that would be too much work on your end troubleshooting it :-).
.
- References:
- Prev by Date: c# sniffer filter
- Next by Date: how can i programmatically enable /disable "File and printer shari
- Previous by thread: RE: Half the speed migrating from Windows 2000 to Windows 2003
- Next by thread: Re: Half the speed migrating from Windows 2000 to Windows 2003
- Index(es):
Relevant Pages
|
|
