This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Images - Where do they go ?
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
After going through several articles and posts and comments about images, I've decided to devote some space to the issue here. The treatment will be done at system-wide levels, meaning with an eye on all the *ilities. The debate is between saving images to the/a database vs saving them to disk. My choice is disk. Here's why.
First of all, some history. Once upon a time, the way all web apps handled images was with the <img> tag using the "src" attribute to point to the relative location of the image on the server's disk.
Over time, the idea of keeping all entity information together spread, and we began saving images to the database, and then returning them to the client by streaming them over HTTP. We began using the "src" attribute of the <img> tag to point to .aspx pages or .ashx handlers which would return the image to us. Thumbnails and zoomed in images were created on the fly by these techniques and everything worked. But not for long. These techniques begin to break down when the load increases.
What are the problems that occur when saving images to the database ? Well, for starters, if you save the image in the same table as you store the rest of the entity's information ( for instance your employees table ) you will most likely overrun the page size for the row causing it to be split over multiple pages. This adversely affects performance. ( Note: if you do decide to go this route, I suggest creating a separate image table where you have an Id and the image itself. Then, from your entity table - employees - use a foreign key to the image table. )
Although the previous problem adversely affects the performance of the database engine, this next problem is more of a gotcha. When saving images to disk on the server, the client is able to cache them by itself to its own disk. This reduces the web server load over time as it has less bytes to serve. When images are referenced by "GetImage.ashx?EmployeeId=12", although you can cache the bytes retrieved from the database in memory on the web server, the client doesn't cache them to its disk. This further reduces the scalability of the system.
Finally, consider the issue of multiple sizes of images - thumbnails, zooms, etc. Although these can be dynamically generated quite comfortably with "GetImage.ashx?EmployeeId=12&Width=100&Height=100", this increases ( per request ) the number of CPU intensive operations needed. A prefered alternative is to automatically generate all the image sizes required once, save them to disk, and serve them like any regular image.
Personally, I use an Imaging service for all of these needs - saving the original image to disk, generating thumbnails, getting the path of an image for a given entity ( eg. employee ) and a given size ( eg. zoom ).
Finally consider the case where you have a large volume of images to serve. Better to have a single server, with ultra-fast disk access + Raid, which serves all images. This server, when separated from the database server, would greatly increase the manageability of the server farm and make diagnosing performance problems much easier.
To conclude, although an interesting capability, saving images to the database begins to pale when compared to alternatives under load. Don't get me wrong, for small systems it may be the simplist :) thing to do, but, time and time again, that small system you built 2 years ago is required to scale and support much more than you originally intended. And, its really not that hard to work the "old fashioned" way. ( Note: run-time generated graphs based on data should not be moved to disk. )
Previous Topic
