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 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
