Tons of caching options.. tried quite a few.. - squid/similar proxy.. - the image streaming/serving script stores the image in /tmp, if the script next time sees the time file (perhaps using databaseid.img filename format) it serves it from disk.. maybe checking the last changed timestamp or something - written a custom caching servlet to request the image from db once, and then serve it from memory for a pre-determined cache time, at which point it re-request/re-caches new object in memory..
On Tue, 28 Sep 2004 11:50:37 -0700, Ed Lazor <[EMAIL PROTECTED]> wrote: > I read through the article and ran some more tests. The new scripts and > tables provide similar initial latency, but I think the test results show > them to be faster overall. > > When it comes to latency, direct file access is still the champion without > caching. I think you made a good point about throughput which makes MySQL > more appealing for storing larger files. That kind of surprised me > actually, because I always figured I'd have to store things like PDF's on > disk and control access to them by putting them outside of the document > root. > > There's still a question of whether caching provides the edge and at what > cost. I haven't set up caching, so I'm not sure if it's complicated or not. > It would provide performance boosts to more than just images through, so it > seems worthwhile to explore. That's what I'll be exploring next. =) > > -Ed > > > > > > -----Original Message----- > > Most people make the mistake of using the biggest blob size to store > > files.. That blob size is capable of storing just HUGE files.. What > > we do is store files in 64K (medium blob) chunks.. > > > > So if the image was say 200K in size, the metadata for the image would > > be 1 row in a table, and the image data would be 4 rows in the data > > table. 3 full 64K rows + 1 partially used rows. > > > > There is a good article/sample code here on the kind of technique we > > started with: > > http://php.dreamwerx.net/forums/viewtopic.php?t=6 > > > > Using chunked data, apache/php only needs to pull row by row(64k) and > > deliver to the client, keeping the resultset size low = memory > > overhead low. > > > > The storage servers (mysql storage) I have tested on the LAN; them > > storing and retreiving data from mysql (using FTP gateway) at rates of > > 4600K/sec.. which is I think the fastest speed my laptop network card > > could deliver. > > > > That's pretty fast.. Rare day when most internet users can talk to > > servers at those speeds. > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
