ASP.NET page content in database vs file performance?

Question

I am creating a site whose content is dynamic and has images in it. What/How much performance hit will my DB (MSSQL) take if I save content/Images in DB?

I am just trying to understand what kind of problems I may run into. I appreciate any responses.

Thanks!

Answer 1

If you store your images in DB, database size will increase and this will result in slower DB queries. Better store on other media and guide your DB to do the stuff for you.

Answer 2

If you keep content (e.g. images) outside of the database, you can let IIS serve this content directly without calling ASP.NET at all (and as a consequence, no database access is needed).

You can even put static content on a different server is you have huge load (like here on StackOverflow).

So if you need to scale in any way, keep static content outside of both ASP.NET and database.

Answer 3

In the company where I'm employed we are using a custom-made CMS.
It renders content and controls for a page dynamically. The content are stored in a table for all pages, (each page has one main content), and other tables store information regarding UserControls, path to it, and which properties should be set with which value via reflection.
The performance is good, even for lets say 10 dynamically created controls. Our biggest client's page has about 70k hits a day and there is no performance problem. The page renders really fast.

Storing the images in your database can also work.
Just keep in mind that you need to use server-side caching for your images (e.g. get them via a generic handler *.ashx and use chaching there) and hope that your imageurl gets recognized for clientside caching.
If you want to be sure, expose your images directly on a dedicated image application. (e.g. www.foobar.com is your URL, then you can create images.foobar.com and store all your images there)

If would definetly advise to store often used images there, like images for the layout, or userpictures (if you are using a forum, or some kind of web application that uses several pictures all the time). But there is nothing wrong with storing not often used pictures in the database (user related uploads et cetera).