Web.Config is Cached

There was a question from a student over on the Asp.Net forums about improving site performance. The concern was that every time an app setting was read from the Web.Config file, the disk would be accessed. With many app settings and many users, it was believed performance would suffer.

Their intent was to create a class to hold all the settings, instantiate it and fill it from the Web.Config file on startup. Then, all the settings would be in RAM. I knew this was not correct and didn't want to just say so without any corroboration, so I did some searching.

Surprisingly, this is a common misconception. I found other code postings that cached the app settings from Web.Config. Many people even thanked the posters for the code.

In a later post, the student said their text book recommended caching the Web.Config file.

OK, here's the deal. The Web.Config file is already cached. You do not need to re-cache it.

From this article http://msdn.microsoft.com/en-us/library/aa478432.aspx

It is important to realize that the entire <appSettings> section is read, parsed, and cached the first time we retrieve a setting value. From that point forward, all requests for setting values come from an in-memory cache, so access is quite fast and doesn't incur any subsequent overhead for accessing the file or parsing the XML.

The reason the misconception is prevalent may be because it's hard to search for Web.Config and cache without getting a lot of hits on how to setup caching in the Web.Config file.

So here's a string for search engines to index on: "Is the Web.Config file Cached?"

A follow up question was, are the connection strings cached?

Yes. http://msdn.microsoft.com/en-us/library/ms178683.aspx

At run time, ASP.NET uses the Web.Config files to hierarchically compute a unique collection of configuration settings for each incoming URL request. These settings are calculated only once and then cached on the server.

And, as everyone should know, if you modify the Web.Config file, the web application will restart.

I hope this helps people to NOT write code!  

Steve Wellens

19 Comments

  • I did *not* know this...I thought the values were read with each request. Thanks for sharing!

  • This even applies to custom configs such as those created with the CSD project.

    If you check the hash-codes of the object in the configuration tree, you will see that they don't change until the app restarts.

  • It's also worth bearing in mind that some configuration sections - include appSettings and connectionStrings - can be overridden by web.config files in sub-directories. If you load and cache the settings on the first request to the site, the values you cache will depend on the URL of the first request, and might not be valid for other requests.

    For example:
    /web.config - sslRequired = false
    /secure/web.config - sslRequired = true

    If the first request is for "/default.aspx", the cached value will always be false; if the first request is for "/secure/default.aspx", the cached value will always be true. If you remove the caching code and call WebConfigurationManager.AppSettings["sslRequired"], you'll always get the correct value.

  • This information is valuable. I would like to know one more thing - Is this behavior same for an App.config?

  • App.Config is also cached but must be refreshed programmatically.
    msdn.microsoft.com/.../system.configuration.configurationmanager.refreshsection.aspx
    (Or, you could just restart the application).

  • Thanks for sharing.

  • Thank for sharing. this has been a big question to me for a long time. but not any more. ;-)

  • I didn't know this. Thanks for sharing.

  • thanks for sharing a good information

  • Steve, This is news to me, thanks for sharing.

    I was sure that I had read the opposite was the case from a reputable source... after a bunch of searching I have found this article http://www.msjoe.com/2009/07/global-application-settings-and-the-web-config-file/ which states that using web.config settings results in multiple reads from an xml file per page request. Even if its not true that the xml file is read then it seems that (according to comments in the page I linked above) the performance of it is still slower than storing your variables in static variables.

    There is also the consideration of writing testable classes.

    I guess like most subjects its not a simple open and closed case.

  • That article is from Joe Stagner so we certainly have to give it some respect!!!
    If you consider this behavior of the cache (described in one of the links above):

    It is important to realize that the entire &lt;appSettings&gt; section is read, parsed, and cached the first time we retrieve a setting value.
    ...it might explain how performance measurements could be thrown off. &nbsp;The first access would be much, much slower than subsequent accesses.

  • Does the caching only applies to the section only or the entire file content?

  • Thanks for sharing!!!

  • Thank you so much for sharing such a great tip!

  • This one is common fact :) but many of developer guys dont really know this; thx for writing this one.

    But if you are using any custom xml/text file for retrieving values inside the application you can use caching(use Generic Dictionary and HttpRuntime.Cache to create it); it will definitely improve performance.

    :)
    regards
    Isaiyavan Babu Karan

  • Thanks for the Info...

  • Thank you very much for that. I am busy going through the Microsoft Visual Studio 2010 ASP.net training and thought I should clear this issue once and for all for myself. They do explain how the web.config files get worked out (flattened) at every level. I was just still not 100% sure the user settings also gets cached, and now I know!

    My "CLEVER" boss told me that I have to cache the user settings, otherwise it is too "EXPENSIVE" reading from disk. (Not even a mention of parsing the Xml.) Well, so I did. I suppose now I can go and change EVERYTHING back to just request the web.config directly. :)

  • stumbled upon your article from google.

    If a section of web.config is encrypted using DPAPI or RSA, will it be decrypted and cached?. or will the app be decrypting the section everytime it needs the info ?

  • Since the documentation says this:

    "It is important to realize that the entire &lt;appSettings&gt; section is read, parsed, and cached the first time we retrieve a setting value. "

    ...I would assume the reading and parsing includes decrypting.&nbsp;
    And it would be a bit crazy to have to include some trigger so that when a cached variable is accessed it would be decrypted first.


Comments have been disabled for this content.