Re: mmap in php_passthru_fd in file.c ?

From: Date: Fri, 18 May 2001 06:49:49 +0000
Subject: Re: mmap in php_passthru_fd in file.c ?
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-55713@lists.php.net to get a copy of this message
On Thu, May 17, 2001 at 11:10:57PM -0700, Rasmus Lerdorf wrote: > > >>Perhaps automatic detection could be option? if (filesize > X) > > >>blockread else mmap? It seems like the most intuitive way to implement > > >>it... > > >> > > > > > > Sounds a bit magical. Why not just a block_readfile() function? > > > > > > Mainly the bloat factor, we already have a large core, imho, functions > > shouldn't be added unless there are no workarounds. Also, it requires a > > little too much thought, into what sizes are good for mmap() and what > > sizes are good for block read's (it also requires knowledge of mmap(), > > because many people might automatically assume that block_read would > > always be faster). I'm pretty sure if we polled php-general and php-qa > > (the more "knowledgable" user bases), most people wouldn't really > > understand what mmap does, or what it is for or when it is beneficial to > > use it. > > > > As for magical, well a bit, but good magic and internal magic (not > > syntactical magic). I'd assume that most systems have a certain point > > where mmap is no longer more beneficial than reading a file by chunks. > > If we can find a reasonable number (or have a user specify that in a > > configuration option if really necessary), it saves the user the trouble > > of thinking about something which is pretty low-level and it reduces > > bloat. I don't really see a downside to this magic. > > But, the issue here isn't one of which is faster. The issue here is one > of memory usage. If you have a 600M iso image that you decide to > readfile() for a download page of some sort, then you are going to end up > with a 600M httpd process. And soon you will have lots of those as more > people hit the page. mmap will not increase the size of your process as it doesn't call sbrk(). > > So to be truely magical here, PHP would have to check the amount of spare > RAM on the system, divide that by MaxClients and set that as the largest > filesize to mmap() because anything larger could result in the box going > into swap. > > I obviously don't think such a check is feasible. The only real question > here is whether to add a user configurable max-mmap setting or to add a > second function that never mmaps. question is: do we really need this mmap stuff at all? with readfile we should easyly be able to saturate a pipe of any size using just read and write. tc > > -Rasmus > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >

« previous php.dev (#55713) next »