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 WellensCodeProject
