These days it seems that we are building more and more applications that have some sort of CMS functionality in them (whether the whole web site or just some of the pages that can be edited). And while this is certainly a good thing, both for the end-user and the site’s developers / designers it does require that we, as developers, give these sites a little more thought than the simple “brochure” sites require.
One area that requires some thought is how images will be handled. Images are an important part of today’s web and any site that allows dynamic editing of its pages will require the ability to upload and display images. Where to store these images? How to serve these images back to clients? These are some questions I’d like to take a look at (remembering that every site is unique and might require completely different design ideas than those presented here).
File System vs Database Storage
The first question is where to store the actual images, and the debate over this has been going on for years. The file system is good at handling files, but not so good at handling metadata (at least not too easily) and indexing / searching. Databases can handle metadata easily, but aren’t necessarily designed to handle larger objects efficiently. In other words, neither choice is a clear winner, especially if we’re talking about image sizes that average between 256KB and 1MB in size (see the white paper link cited below).
However, with SQL Server 2008’s new FILESTREAM column type and data storage option I think we get a good compromise. With FILESTREAM columns the actually binary data is stored outside the database proper and can be accessed through the file system, but SQL Server maintains a link to the file data inside the database. Some advantages that I see with this system include:
- Database connections aren’t tied up transferring large amounts of data (which might be important as an application scales out).
- Even though the data is in the file system, SQL Server still recognizes it as part of the database and as such backups will backup the file data as well (thus ensuring image data and metadata is always in sync and easy to restore if needed).
- Accessing the file data through the file system’s streaming API can reduce memory usage, which again enhances scalability.
- There are (in theory) no limits to the size of objects that can be stored in the FILESTREAM columns (though I’m not sure how much of an advantage this is in practice).
For more information be sure to read this white paper on SQL Server 2008’s FILESTREAM column type.
Image Sizing (Thumbnails) and Watermarks
It is often necessary to manipulate the images that are uploaded in some way, whether generating images of different size, added a watermark of some sort, or even more advanced operations such as creating grey scale images. What is the best way to do this?
Going on the assertion by by job’s IT department that “disk space is cheap, processing power is not” rules out (in my opinion) some sort of on-the-fly manipulation. Though this could be done, the memory and processing requirements make this type of solution hard to scale. The same principal applies to adding watermarks to images: doing this on the fly, while possibly easier to implement than storing watermarked images, will result in a solution that is more resource intensive (processor and memory wise) in the end.
Thus, I believe the best solution is to preprocess the images (resize, add a watermark, etc.) and to store those preprocessed images. This will require more storage space, but in the end it is easier (and cheaper) to scale disk storage than memory or processing power. Additionally, this will result in the best performance (image download time) for the applications end-users, which is a good thing.
Speaking of which, for applications that need thumbnail images you should definitely create thumbnails on the server and use those as opposed to just setting the width and height in an <img> tag. The reasons for this should be obvious (a 200KB images takes less time to download than a 2MB image).
Caching
One thing that I often see overlooked when people write code for image handlers is setting the HTTP cache headers. Setting these headers can be an important performance boost for you application, especially if the images are used in multiple places on the site (or on the home page or pages that users will often navigate to.) Setting the appropriate cache headers (and recognizing headers in the request such as "Is-Modified-Since” and responding accordingly) allow the client’s browser to effectively cache the images, reducing bandwidth usage and speeding up page rendering times.
Other Considerations
There are other considerations to dynamic image handling (like how to identify them: by name, keyword, ID, etc.) but I think the above three are the major ones to consider when designing an image handling system. If you get the storage as efficient as possible and enable client-side caching you are well on your way to a well-performing and scalable image handling solution.
до свидания!!