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
- 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 <ed.lazor@stripped> 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
> 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. =)
> > -----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.