Take the 2-minute tour ×

I use Web Forms and Asp.Net with MS SQL.

For my Web Site I need store these codes belove, maybe others in future:

  • Google Analytic Code
  • Some JavaScript codes
  • HTML Footer and Header for my template.

I need a solution which could be centralized, use CACHE, easy to update:

Here my ideas, I would like your opinion:

  • 01 Use a DATABASE with a Table (configure table) which for every records (VARCHAR) would allow storing of these spinets of code as string.
  • 02 Use simple Text Files in a specific folder, so I can include these files in my code. I could update codes using FTP and NotePad (Here I am concern about cache).
  • 03 Use Web.Conf file.
  • 04 Use Text File and a Class wich would manage storing in cache the content of these file.

Any ideas? Thanks for your time.

Here I would like highlight and useful article for this topic:


share|improve this question
Why not just put them in a partial view? And html header/footer in the master-view. –  CodesInChaos Dec 16 '10 at 18:58
Don't worry about disk IO. Network IO is exponentially worse. Also, cache is not an abbreviation. –  SLaks Dec 16 '10 at 19:07
Your examples will most likely be cached by the OS disk cache even if you use plain files. I know some disk bounded applications, but those usually have multi GB databases. –  CodesInChaos Dec 16 '10 at 19:57
add comment

2 Answers

up vote 3 down vote accepted

First off, regarding the referenced link to Nathanael Jones blog, although disk IO is much slower than in memory operations most websites are not disk IO bound, and most of his solutions are quite frankly uneducated crap.

Generally speaking there are only a very few situations in which you become DISK io bound. The first is the database server itself. If it doesn't have enough RAM to keep the relevant parts of the database in memory then disk speed of THAT server is crucial; especially in a high transaction situation.

Second, you can be disk IO bound if your application directly reads and writes a lot of files. Very very few apps do this. I'm not counting the .aspx or.html files of your application because those can be cached by the existing framework and IIS.

Basically, just ignore him.

The whole filesystem to database syncing idea as a method to improve performance is of no value to about 99.999% of sites. If nothing else the database should be pushing files to the web server file system, not the other way around. I have seen exactly 1 site in 20 years of development that required this. They serve several million page views a day. Also, he is flat wrong about making a database call across a network being faster than loading an equivalent amount of data from a local file.

Next, the actual area that we are really bound at is in sending data across the network to the client browser. This is ALWAYS slower than reading a file from a disk; even with no traffic on the line. Hard drives move data much faster than your network card can. Taking it one step further; modern hard drives are orders of magnitude faster than your internet connection. The best thing you can do to improve performance is just to limit the number of connection requests a single page load requires. Optimization here means having 1 css file, not 20; having just a couple .js file references, not 100; and combining graphics into sprites where feasible. It's faster to transfer 1 big file than 100 small files due to how TCP works.

Maybe on an overloaded shared server you might have an issue. However, the reality is that an overloaded shared server is going to be network congested long before it's disk queue length grows out of control.

With that out of the way, let's look at your actual issue.

The javascript items have two preferred locations: 1. As .js files on the web server or 2. embedded in your master page. Just do option 1, they will be cached by the web server. Further, they will be cached by the client browser meaning you won't have to

For your header and footer, the code for this should be in your master page. Don't do server side includes, that just complicates things. Build a normal .net website that leverages master pages for your "chrome" content. You can enable partial page caching at the application level which will handle all of caching for you.

When you update the header or footer content, just redeploy the site.

share|improve this answer
Thanks for your message, I will think about it! I also think SSI is not a great solution and maybe a bit out of date thanks –  GibboK Dec 20 '10 at 11:26
What about add HEADER and FOOTER to the DB and include a reference to a Master Page? In this way I could update the website without redeploy it and have more manageable site. Do you think I can have slow performances in this way? Thanks once again for your time –  GibboK Dec 20 '10 at 11:30
@GIbboK: Putting the header/footer in the DB is just fine. These can easily be cached by your data access layer as well; perhaps with a expiration of around 20 minutes or so. –  Chris Lively Dec 20 '10 at 14:18
add comment

Store your headers and footers in files and use Server Side Includes. Some web servers(IIS 6.0) may allow you to add document footers to all the pages.

Store your Javascript in files and use the in your pages. This will allow caching and improve page performance.

share|improve this answer
What about SSI and CACHE? Are the stored in CACHE? What about update? IF i Need change the header do i need log in in IIS? thanks –  GibboK Dec 16 '10 at 17:58
@GIbboK - See "Enabling Content Expiration" in flylib.com/books/en/ –  DaveB Dec 23 '10 at 16:37
add comment

Your Answer


