> Obviously the mmap will be faster, but if as in bug #10701, someone is
> adding headers or doing something else to really large files, things are
> going to break.
There seem to be some misconceptions about what we are really
doing. We map a shared(*1), read-only copy of the file into
our address space, we don't allocate any memory, we don't
operate on the mmap'ed area, and this does not change when
you "add headers or do something else to really large files".
The process of mapping does not cause a read of the whole
file at once nor does it allocate memory for the whole file.
When pages are accessed, a memory fault is generated and the
data is fetched from the disk. When there is not enough free
physical RAM for storing the contents of a new page, old
pages get thrown away (they are read-only, so there is no
reason to swap them out). (*2)
For delivering a 600MB ISO image, the simple read/write
approach with a 2KB buffer will cause about 600,000
context switches. The mmap implementation will need less
than 10. This can significantly decrease the load on busy
web-servers.
By leveraging the power of the underlying OS's buffer cache,
we enable the OS to handle the dirty aspects of writing huge
amounts of disk data to the network. Most modern OS have
certain optimizations to deal with that task in the most
efficient way (i.e. zero-copy, sendfile()). The simple
read/write approach circumvents all possible optimizations by
OS designers.
I just ran a quick test with a >400MB ISO image, Apache 1.3
CVS, PHP 4.0 CVS on a system with 256MB RAM. The results of
http_load are below.
40 fetches, 20 max parallel, 1.68437e+10 bytes, in 361.079 seconds
4.21093e+08 mean bytes/connection
0.110779 fetches/sec, 4.66484e+07 bytes/sec
msecs/connect: 18.0746 mean, 692.648 max, 0.072 min
msecs/first-response: 1116.32 mean, 3546.76 max, 48.349 min
*1 There is a bug in the current code, as we should be using
MAP_SHARED. This might be contributing to what the user
is describing in #10701.
*2 Some Linux 2.4.x trees seem to be broken in that respect and
don't free pages quickly enough (or not at all). This
causes the system to freeze. Linux 2.2 works as expected.
I experienced this effect on 2.4.4-ac1 (TUX patch).
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
