MySQL Forums
Forum List  »  PHP

Re: Store GIF in Blob and show GIF on page
Posted by: Ulf Wendel
Date: August 23, 2006 01:46AM

Please do not expand this. Storing images in a database instead of links to the images is bad style. Some problems.

a) People start to use <img src="sendimage.php?image=myimage">

Ok, say you have one index.php which generated the above HTML output. If the user opens the index.php in its browser, the script sendimage.php will be called. That gives:

1 web server process for the image.php
n x 1 web server process for the sendimage.php

And very likely also:

1 database connection for the image.php
n x 1 database connection for the sendimage.php

With n beeing the number of images on the page index.php. With other words, this approach requires n-times more processing than an index.php which reads the _path_ to the image from the database and prints out <img src="/path/to/myimage.gif">. If you want to slow down your web server to 1/n of its performance, great, go on and kill your web host.

b) <img src="sendimage.php?image=myimage"> prevents the usage of specialized, fast web servers

Apache is a slow, large monster web server. Many slim and fast web servers exists which can serve images a way faster. Use extra web servers for media files, e.g. images and use <img src="http://myimageserver.com/path/to/myimage.gif">;. Use the fat and slow Apache only for serving the complex pages which require complex web server software

c) Databases are not optimized for BLOBs

In almost every database, BLOB storage is not very much optimized. That's because BLOBs are too large to be stored on the same database page as the other columns of a row. This leads almost always to extra fetch operations and more hazzles with the database cache population etc. - simply avoid reading/writing BLOBs frequently. It's extremly difficult to optimize the physical storage for BLOBs in general. MySQL is no exception to this.

d) max_allowed_packet

People always run into this limit, sooner or later. OK, only a configuration issue and the protocol limit of 1GB is not that much of an issue.

But there is another problem AFAIK: no chunked reading, the client has to read all bytes at once. If the BLOB is 10MB the client has to allocate a 10MB buffer. It cannot fetch 10 smaller 1 MB chunks from the server. The client will allocate large buffers which can become an issue if your BLOBs become large.

Conclusion: storing images in the database is very likely to slow down your PHP application and increase server load dramatically. Using paths to images and storing them inside the database is usually much better.

... and one final word about this incredible inefficient 1), 2), 3) that people requests:

1) inefficient storage inside the DB: extra access operations, likelyhood of bad cache usage figures increases
2, 3) extra load on the file system, extra CPU cycles, extra load on the database - what is so hot about getting some cakes from the supermarket, wrapping them out, wrapping them in again, putting them into the shelf, fetching them from the shelf, wrapping them out again to eat some vs. buying, storing, eating.

Ulf

Options: ReplyQuote


Subject
Written By
Posted
Re: Store GIF in Blob and show GIF on page
August 23, 2006 01:46AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.