Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: [PATCH]: emulate_sendfile fix [WAS]: File buckets
	v.	core_output_filter
From: Bojan Smojver <bojan@rexursive.com>
To: Apache Dev List <dev@httpd.apache.org>
In-Reply-To: <405F510C.7000807@wstoddard.com>
References: <1060256982.1293.28.camel@beast.rexursive.com>
	 <1079986458.1336.5.camel@coyote.rexursive.com>
	 <405F510C.7000807@wstoddard.com>
Content-Type: text/plain
Organization: Rexursive
Message-Id: <1080006019.1410.211.camel@beast.rexursive.com>
Mime-Version: 1.0
Date: Tue, 23 Mar 2004 12:40:19 +1100
Content-Transfer-Encoding: 7bit

On Tue, 2004-03-23 at 07:48, Bill Stoddard wrote:

> I took a 15 second look at the patch and have a concern (perhaps unfounded).  apr_file_seek() is probably an 
> expensive operation.

I've had a quick look at apr_file_seek() function and the cost depends
on how the file is opened. If it's buffered, we might get away without
actually calling lseek(), depending on where we are in the file. If the
file is not opened as buffered, we're doing an lseek() for sure. This is
all on Unix, of course. Wouldn't have a clue on other platforms.

I have no idea how lseek() syscall is implemented on various kernels.
Who knows, maybe it compares the current position with the requested
one. Whichever way it works, we're still down by a syscall. The good
thing is that this path of execution _only_ takes place is sendfile()
isn't in action for whatever reason (no platform support, file wasn't
opened with APR_SENDFILE_ENABLED flag etc.). This should be rare
(wishful thinking? :-)

I did two quick benchmarks with sendfile() support turned off in order
to determine rough impact of the patch on emulate_sendfile() and the
whole of Apache (prefork MPM). The tests were done on a 2 GHz Celeron
system, running Fedora Core 1. They were fetching the default Apache
page (in English), 1,456 bytes long, 1,000,000 times using ab.
Connections were not kept alive and concurrency level was 1. I have
checked through gdb and made sure emulate_sendfile() was used for both
tests.

The first test had the patch in (i.e. it was doing an extra
apr_file_seek()), the second one didn't. The patched Apache was able to
serve 648.34 request per second (or total time for the tests of 1542.412
seconds). The unpatched Apache was able to serve 656.85 request per
second (or total time for the tests of 1522.414 seconds). This would
mean that the patch made Apache only 98.7% as fast as the unpatched one
(or, we lost 1.3% of speed) on platforms/directories/files that use
emulate_sendfile() exclusively. For what it's worth...

BTW, if anyone has a better idea on how to fix this problem (and I guess
it should be something along the lines of dragging around the position
within the open file), I'd be interested to know. I'm not all too
familiar with core.c file - maybe there are slots available we can whack
this information into. In any event, it seems to me that present code
does have a bug.

-- 
Bojan