Re: mmap in php_passthru_fd in file.c ?

> 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