>> > I'm making assumptions about the layout again. The database will >> > likely already have the table files opened, but will need a seek to >> > get the data. The webserver will have to do an additional seek (I was >> > assuming on a far slower drive system, and likely twice for stat and >> > read). >> >> I'm not sure I trust this assessment.If it is an often used image it >> will >> be in OS level cache. If it is not, then you will have the I/O. >> Regardless, it will be using SQL database cache blocks and reduce the >> efficacy of the SQL cache. > > Remember, I don't use a db to store images, for a variety of reasons, > mostly in that centralized repositories of anything don't scale. Finally someone has something that sounds like a well constructed thought. > However, if your hardware is far more than than you userbase will > need, the SQL server's caching won't matter, and it will be faster. The "good enough" fallacy again. > Not that it matters, since it would be a more expensive setup than > necessary. Using hardware and resources more effectively is seldom more expensive. > Ease of programming wise, or in the one case where we use > it: ease of developer setups, it works better. I've never seen it in practice. A trivial procedural rule during development is not a big deal. > Those are really just > configuration issues and a syncing issues across platforms. > > Storing everything on one machine does not scale. > > And as to the "slashdot effect" -- snore. It is a handy "short hand" for heavy access, and it is a big concern if you have a popular site or hope to have one. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
