From dev-return-11509-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Mon Apr 12 16:15:12 2004 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 25062 invoked from network); 12 Apr 2004 16:15:12 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 12 Apr 2004 16:15:12 -0000 Received: (qmail 53112 invoked by uid 500); 12 Apr 2004 16:14:56 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 52980 invoked by uid 500); 12 Apr 2004 16:14:55 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 52952 invoked from network); 12 Apr 2004 16:14:55 -0000 Message-ID: <407AC068.4080102@wstoddard.com> Date: Mon, 12 Apr 2004 12:14:32 -0400 From: Bill Stoddard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@httpd.apache.org, dev@apr.apache.org Subject: Re: Performance of TransmitFile on Windows Servers with 2.0.49 References: <407AB3B0.9000105@cisco.com> <407ABC60.7000906@wstoddard.com> In-Reply-To: <407ABC60.7000906@wstoddard.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Bill Stoddard wrote: > Philip Gladstone wrote: > >> I noticed that the performance of TransmitFile (used when EnableSendFile >> On on Windows platforms) was significantly worse than EnableSendFile Off. >> >> It turns out that the way that TransmitFile is called is *without* the >> TF_WRITE_BEHIND flag. This means that TransmitFile does not complete (or >> rather that the socket is not signalled) until *all the data* has been >> ack'ed by the client. Windows clients send acks (roughly) every other >> data packet, or after a 200ms timeout. Thus, about half the time, the >> TransmitFile does not complete until this 200ms timeout has triggered. >> >> This reduces the throughput on high speed networks significantly. On a >> 100Mbit LAN, the throughput drops from 11MBytes/sec to around >> 2.5MBytes/sec. >> >> My question is: is there a good reason that the TF_WRITE_BEHIND flag is >> not being used? Try applying this patch to apr and let me know how it works. Bill $ cvs diff -u sendrecv.c Index: sendrecv.c =================================================================== RCS file: /home/cvs/apr/network_io/win32/sendrecv.c,v retrieving revision 1.64.2.1 diff -u -r1.64.2.1 sendrecv.c --- sendrecv.c 13 Feb 2004 09:33:51 -0000 1.64.2.1 +++ sendrecv.c 12 Apr 2004 16:14:17 -0000 @@ -237,7 +237,7 @@ apr_status_t status = APR_SUCCESS; apr_ssize_t rv; apr_off_t curoff = *offset; - DWORD dwFlags = 0; + DWORD dwFlags = TF_WRITE_BEHIND; DWORD nbytes; OVERLAPPED overlapped; TRANSMIT_FILE_BUFFERS tfb, *ptfb = NULL; @@ -323,6 +323,7 @@ /* Disconnect the socket after last send */ if ((flags & APR_SENDFILE_DISCONNECT_SOCKET) && !sendv_trailers) { + dwFlags = 0; dwFlags |= TF_REUSE_SOCKET; dwFlags |= TF_DISCONNECT; disconnected = 1; @@ -333,7 +334,6 @@ #if APR_HAS_LARGE_FILES overlapped.OffsetHigh = (DWORD)(curoff >> 32); #endif - /* XXX BoundsChecker claims dwFlags must not be zero. */ rv = TransmitFile(sock->socketdes, /* socket */ file->filehand, /* open file descriptor of the file to be sent */ nbytes, /* number of bytes to send. 0=send all */