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
