Web.Config AppSettings & Caching

[Fred Nelson]

Hi:

I have written several web applications that obtain their connection
strings from the web.config file. This is very easy to use and it makes
it easy to move an app from development into production.

I'm in the process of writing a site that will have lots of traffic so
I'm trying to save resources everyplace that I can.

My question is - do the web.config app settings get loaded once when the
application starts - or does the application read the entire XML
web.config file everytime that I request the connection string.

If the web.config is read each time then I will create a simple class
library to return the string.

Thanks for your help!

Fred

 

[Karl Seguin [MVP]]

It's cached after the first request to it.

Karl

 

[Terry Burns]

If you overwrite the web.config, the application restarts. This is an
indicator that the entire file is read when the application starts or it
would not need to restart it.

The better approach is to store configuration settings for the application
in an SQL sever, this way if your application dynamics change you dont need
to interupt service to its users.

 

[Kevin Spencer]

The better approach is to store configuration settings for the application

in an SQL sever, this way if your application dynamics change you dont
need to interupt service to its users.

Unless one is developing a database application, this isn't a good idea.
Licensing for SQL Server is quite expensive.

Some other considerations: Having to fetch frequently-used data that doesn't
change very often from a database repeatedly is a performance issue. You
could cache the data, but again you run into the problem of changing the
configuration data on the fly and the app not being aware of it. I believe
this is why the web.config file is read once and then cached.

Restarting the app should not be a problem necessarily. First if you are
running IIS 6, this can be done gracefully, with no interruption of service.
If you are using IIS 5, it could cause an interruption in service, but doing
so infrequently and at the right time should minimize the issues involved.
In either case, the application should always be designed to handle a
restart as gracefully as possible, as this is a certain eventuality.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

 

[Terry Burns]

I disagree. MSDE is an alternaive which is free

Restarting the application with 100+ users is a big issue.

Having a change of system constants using an SQL database is far better than
interupting
all your users.

Regards

 

[Guest]

Fred,
As Karl indicated, the config file is processed once when the application
starts, and even that is lightning fast. Further references to config data
come from memory. And I agree that using a database to store configuration
data that doesn't change often is an unneccessary overhead and adds
complexity, unless its an app that already uses a database. In addition, if
the database is where the change of any config data occurs, one would
additionally have to implement SqlCache callbacks so that the app can get the
changed data in a timely manner.

Your focus on a high volume app needs to be more in the area of page
rendering, using caching intelligently and things like excessive use of
Session and ViewState.
Peter

 

[Terry Burns]

Actually it was Kevin, not Karl who said this.

Aside from who actually said it, using caching is not neccesary. On
application start the values can be read into Application keys and read from
there throughout the program. If you want to change this, you can write an
admin utility which changes the Application version of the values when the
SQL data changes. Actually, you dont even need an SQL server, you can use a
DataSet and write/read the values from there, but do it through a
maintenance form which updates the application values. If you are in a
situation where you want to know if the Application values have changed you
can keep two sets of values and have your code check for those changes and
act appopriately.


This way you get the best of both worlds.

 

[Kevin Spencer]

I disagree. MSDE is an alternaive which is free

There are plenty of free databases. This, however, doesn't address any of
the other issues I brought up.

Restarting the application with 100+ users is a big issue.

This is an assertion, not an argument. An argument contains logic that
justifies the assertion. It is stated as if it were always true. It is
certainly *not* always true, and I would argue that if the application is
designed correctly, so as to handle application restarts (which, as I
pointed out in my earlier message, is an inevitable certainty at some
point), and Best Practices are followed, it does *not* have to be a "big
issue."

To further elaborate, Best Practices include (but are not limited to) the
following:

1. Only data which very infrequently changes should be stored in the
web.config file. Data which changes frequently can (and should) be stored in
other ways (such as a database or some other disk-based storage device). The
web.config file is an application configuration file, not a caching
mechanism.
2. The application should be designed so that it recovers its configuration
state smoothly. This is of course mostly dependent upon number 1, but there
are other considerations involving the application startup and shutdown
logic.
3. Changes in the web.config file should be made very infrequently, and when
done so, should be done at a date and time during which the traffic to the
site is lowest, to minimize service interruptions.

Having a change of system constants using an SQL database is far better
than interupting
all your users.

ASP.Net has been around for over 4 years now, and is in its second version.
A large group of the world's best software architects have worked on this
technology, and they seem to disagree with this assertion. Perhaps they have
thought of a few things you have not. I brought up a few of them in my
earlier message, but you didn't address them.

The most salient of these points is that any such settings must be fetched
repeatedly from the database (each time they are used by *any* instance of a
client object), in order for the application to be synchronized with any
changes to the data in the database. Since these settings are stored at
application scope, they are likely to be accessed often. This entails a
performance issue, as well as the danger of any single database request not
succeeding for any reason. This sort of thing *does* happen, especially with
network database servers, which are at the mercy of the vagaries of the
network they reside on. Both the performance hit and the danger of a failed
database call are increased as the size of the application and the number of
concurrent clients increases, which makes this solution unscalable.

The web.config file, on the other hand, is read only *once* at the start of
the app. It's data is cached in memory, and if any changes occur, it is
refreshed from a file, which is not dependent upon the vagaries of a
network.

No solution is perfect. However, based on the facts which I have enumerated,
I would have to agree with Microsoft that their solution is the most perfect
currently available.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

 

[Kevin Spencer]

Actually, you dont even need an SQL server, you can use a

DataSet and write/read the values from there, but do it through a
maintenance form which updates the application values.

Okay, let's drop the requirement for a database and go to DataSet. The
DataSet is stored as an XML file on the server (just like the web.config
file). It can be deserialized and cached in memory when the application
starts (just like the web.config file). So far, we've done nothing different
from using a web.config file.

If you are in a situation where you want to know if the Application values
have changed you can keep two sets of values and have your code check for
those changes and act appopriately.

So, what is this "situation where you want to know if the Application values
have changed?" That would be any time they are accessed. So, how often does
the application have to check the "DataSet configuration file?" Every time
one of those values is needed. So, how often does file IO have to be
employed to read and deserialize the "DataSet configuration file?" Every
time one of those values is needed.

The only difference here between your database solution and your "DataSet
configuration file" solution is that you've gone from a full-blown relation
database server to a file-based database. The database (file) still needs to
be opened with every read of a configuration value. And, as I mentioned in
my most recent reply, this is simply not scalable.

The only difference between your "DataSet confiiguration file" and a
web.config is that the web.config file is read once, when the application
starts, and if changed, restarts the application. As I mentioned in my most
recent reply, there are reasons why Microsoft decided against this model.

But to elaborate even further, these are *application-wide configuration
settings*. They are accessed very frequently, and should be changed very
*infrequently*. Even ASPX pages are not opened with each request for a page.
They are cached. And ASPX pages are not used by almost every object instance
in the application.

I have been known to be wrong from time to time. And I freely admit when I
am. That is how I keep my reputation for being a reliable source of
information. This issue is a tar baby, Terry. The more you whack at it, the
stucker you will get. Might be a good time to back away from it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

 

[Terry Burns]

I think you have the wrong end of the Stick Kevin.!

It can be deserialized and cached in memory when the application

starts (just like the web.config file). So far, we've done nothing
different from using a web.config file.

Yes we have, we can alter the XML file without restarting the Application

So, what is this "situation where you want to know if the Application
values have changed?" That would be any time they are accessed. So, how
often does the application have to check the "DataSet configuration file?"
Every time one of those values is needed. So, how often does file IO have
to be employed to read and deserialize the "DataSet configuration file?"
Every time one of those values is needed.

Hypothetically, there could be situatuion where the application needs to
know
a value has changed rather than simply using the value. As I state later on
in my
reply, the application only needs to read the XML file once at startup
unless
the value changes, wherein the form used to make the changes updates
the Application("myVariableName(s)").

The only difference here between your database solution and your "DataSet
configuration file" solution is that you've gone from a full-blown
relation database server to a file-based database. The database (file)
still needs to be opened with every read of a configuration value. And, as
I mentioned in my most recent reply, this is simply not scalable.

No, you have misread me. The Application Start reads the XML file and
stores them in Application("myVariablesName(s)"). These can then be read
by the application as it runs.

I have been known to be wrong from time to time. And I freely admit when I
am. That is how I keep my reputation for being a reliable source of
information. This issue is a tar baby, Terry. The more you whack at it,
the stucker you will get. Might be a good time to back away from it.

I dont need to back away from something I see very clearly as being valid.
My solution
allows the same functionality as the web.config with one simple difference,
and that
is the user base need not be interupted when a value needs to changed. Now
lets see
your argument aginst this ?

 

[Kevin Spencer]

Now lets see

your argument aginst this ?

I give up, Terry. You're right, and all of the architects at Microsoft are
wrong.

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

 

[Terry Burns]

I fail to see a cogent argument Kevin, where is it ?

 

[Kevin Spencer]

I>I fail to see a cogent argument Kevin, where is it ?

It isn't Terry.

In fact, Microsoft *has* modified the configuration model between versions
1.1 and 2.0 of the Framework. Some settings can be saved to a configuration
file without restarting the application, including some custom configuration
settings.

--

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

 

[Terry Burns]

OK version 2.0 was not specified. So my questions are for 2.0

1.) Can all users settings be changed without the app restarting ?
2.) If 1) is yes, does this update the cached information when the changes
are made to the web.config ?

For version 1.x, my argument stands.

 

[Kevin Spencer]

Hi Teery,

Not interested in arguing, but in answer to your questions:

1.) Can all users settings be changed without the app restarting ?

Configuration Sections which have the attribute "restartOnExternalChanges"
set to "false" will not require an application restart. However, there are
no ASP.Net Sections that can use this.

2.) If 1) is yes, does this update the cached information when the changes
are made to the web.config ?

Again, this doesn't apply to ASP.Net.

Now, if you want to continue arguing, you'll be arguing with yourself. I've
tired of this. It is not profitable to anyone.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

 

[Terry Burns]

You know, I really dont understand you. You seem to think anyone who does
not
have the same view is smply trying to argue for arguments sake.

What happened to 'Debate' ?, A free exchange of views reagrding a given
subject
where two people can discuss something untill a resolution is spit out. ?

It sounds like you are simply tired of things to the point that you just
cant be bothered !

 

[Kevin Spencer]

It sounds like you are simply tired of things to the point that you just

cant be bothered !

Nope, just working about 60 - 70 hours a week, Terry. I have to be very
discriminating with my time.

--

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

 

[Terry Burns]

1.) Can all users settings be changed without the app restarting ?

Configuration Sections which have the attribute "restartOnExternalChanges"
set to "false" will not require an application restart. However, there are
no ASP.Net Sections that can use this.
OK, then what use it this ?

2.) If 1) is yes, does this update the cached information when the changes
are made to the web.config ?

Again, this doesn't apply to ASP.Net.


I must be missing something, you referenced this, but go on to tell me it
has
no use, where am I going wrong ?