It would be quite easy to drop a squid or similar proxy infront to
cache the db images in memory and deliver them for a set cache-time or
something.. That would be 1 way to boost performance..
On Tue, 28 Sep 2004 09:55:54 -0700, Ed Lazor <ed.lazor@stripped> wrote:
> > -----Original Message-----
> > I have heard also that it helps to keep the table with the blobs having a
> > low number of fields. Like just a primary key and the blob field. Have
> > all your other metadata in a seperate table. Especially if you are going
> > to be occasionally doing queries of just the metadata and don't want to
> > always retrieve the image. Comments?
>
> I agree. That's the approach I used. Data on products are stored in a
> products table, while images are stored in a table called images. The
> images table has the following fields: ID, ProductID, SizeID, Image. There
> are 4 images of different resolutions for each product. The SizeID is used
> to tell which resolution is being requested. For example:
>
> Select Image from images where ProductID='8443' AND SizeID='1'
>
> ProductID is an int. SizeID is a small int. The Image field is largeblob,
> because some images are as large as 300k. However, images are generally
> 15k, 45k, 90k, and 180k, so perhaps largeblob is causing a performance loss?
>
> I also plan on using caching tools, so maybe performance tuning on the
> backend isn't as significant? What do you think?
>
> -Ed
>
>
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=1
>
>
