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
