View Full Version : How Expensive are File Reads?
Winters
07-13-2005, 02:49 PM
I wanted to know how expensive file reads are. Like if I'm using a handfull of php includes for heading and footing and menu's and stuff. Should I be using a database instead or is the file read time and processing time mostly negligible.
I remember I wrote a scrip once (not on FQ severs) that opened, read, and closed a file 10,000 times and reported the execution time, it didn't take very long at all, I was really surprised. Evidence seems to show that file reads are not very expensive, but intuitively it feels wasteful.
Kevin
07-13-2005, 02:52 PM
File reads are not very expensive unless you are excessive about it. 10,000 of them in a single web site would be VERY excessive. Less than 10 should be fine and for the type of stuff you are talking about a database wouldn't be very efficient.
phppete
07-13-2005, 02:55 PM
File reads and includes are different though so I assume includes (require_once()) are not very server intense, reads as in fopen() would be though wouldn't they?
Kevin
07-13-2005, 02:57 PM
BTW, in your benchmark you said you opened a file 10,000 times but that isn't a very good benchmark because if you open the same file more than once you are just pulling it from the cache. For a real benchmark you would have to open 10,000 different files not that I recommend doing it ;)
Winters
07-13-2005, 03:22 PM
BTW, in your benchmark you said you opened a file 10,000 times but that isn't a very good benchmark because if you open the same file more than once you are just pulling it from the cache. For a real benchmark you would have to open 10,000 different files not that I recommend doing it ;)
Thanks for letting me know. I wasn't expecting the benchmark to be any kind of highly accurate experiment, but just a huge generality to give me a really rough idea, but it makes sense what your are saying about reading the same file repeatedly. When I did it only once and timed it, it was such a small time that I didn't believe it, so I repeated it with 10,000 just to help convince myself. It's just very very counter-intuitive to me.
I started to think about it and worried a little bit. One page request has the page itself, 4 or 5 images, the CSS file. Possibly JS files. 3 or 4 PHP includes. Maybe php classes in their own separate files which also might call for other files. I guess one page request might have about 10 to 15 file requests associated with it in some cases, which was a little bit of a surprise when I stopped to think about it.
Like is this the kind of thing that makes the site die if I ever received a spike of traffic?
Thanks again :)
Bruce
07-13-2005, 03:34 PM
It's just very very counter-intuitive to me.How so? Opening and reading files is a very, very common operation in operating systems, and so they optimize that path heavily. Linux caches disk data (which tells where the files are located), but also caches the actual file data and the filenames, so that accessing a file a second time doesn't even have to decode any data.
I started to think about it and worried a little bit. One page request has the page itself, 4 or 5 images, the CSS file. Possibly JS files. 3 or 4 PHP includes. Maybe php classes in their own separate files which also might call for other files. I guess one page request might have about 10 to 15 file requests associated with it in some cases, which was a little bit of a surprise when I stopped to think about it.Add to that a few other files: for each individual request (your paragraph counts as 6+ requests, PHP includes don't count), Apache has to traverse up the directory tree to find all .htaccess files and read and parse them.
Like is this the kind of thing that makes the site die if I ever received a spike of traffic?It really depends on the exact numbers, and what is actually being done in the includes. If it is strictly just simple header/footer types of things it's not a big deal until the traffic spike reaches "slashdot effect" proportions. If you're doing heavy data processing, a bad spike would be much smaller.
PaulKroll
07-18-2005, 01:50 PM
intuitively it feels wasteful.
This is one of those places where intuition is wrong. Yes, file reads can take up a lot of time. But a web page that has 50 file reads probably still takes a small fraction of the time that, say, 50 database queries would take.
Remember, the database is doing file reads too. :)
vBulletin® v3.6.8, Copyright ©2000-2012, Jelsoft Enterprises Ltd.