Web.config production environment performance - Best practices

In Visual Studio, when we develop, the web.config file is often modified but I don't know what is modified, and what are consequences in production envirionment for performance, and if configurations sections are important.

For example :

<compilation>
<compilers>
<runtime>
...

There are lot of sections I thinks are not essentials, and without it or with another configuration, can improve performance in production environment.

So my question is :

What are you looking for in web.config file in production environment to not to lower performance and have a light configuration file ?

What are best practi开发者_开发技巧ces ?

Thanks for your answers !

In Web.Config you can configure whether you want debug assembles or release assemblies. You can tune the performance of WCF, thread pool. You can configure logging, etc.

Visual Studio doesn't change critical settings for you automatically. The only thing it does however is enable debug assemblies when you're trying to debug your app. It asks you for confirmation in that case. For production you can disable debug assemblies.

I would recommend you to use a diffmerge tool to see what sections are added since last commit. However please note that shorter config doesn't necessarily mean better performance.

Your web.config is merged with machine.config which has many sections. So not putting a section usually means you're not modifying the defaults in machine.config. Adding a section doesn't mean you're adding something new. It only means you're configuring something that will have otherwise some default setting.

As far as best practice is concerned. It is advisable to have a short config file to make it more maintainable. There is no point in specifying the defaults in the config again if they are implicitly default or are otherwise in machine.config anyway. VS2010 already avoids unnecessary sections.

The number of sections in a web.config file has nothing to do with performance.

Some machines will require more things configured than others (hence a size difference) in order to run the same application.

As Hasan pointed out, the web.config is merged with the machines config file. You might very well have 1 machine (call it test) which defines things in it's machine.config that isn't defined in your production config. So, for test you might not need certain sections that production would require.

Also, the machine configs for a particular item might vary. In a web farm scenario it is common practice to override the machines config file with a common machinekey. This doesn't have a performance impact but does impact whether you are going to be successful in load balancing the site.

To iterate: the number of sections is immaterial to performance. The contents of defined sections, on the other hand, is.

Now, how to improve performance: This is on an application by application basis. For production you will want to turn off debugging, and turn on things like url compression for static content.

You might want to turn on compression for dynamic content as well or even configure certain directories to inform the browser that content is cachable (like /images, /css, or javascript). Incidentally, these would generally increase the size of your production config file and has certain consequences (like when you want to change a css file), but will generally yield improved performance for the client.

For other items you might turn off logging or use a completely different logging storage provider. We use elmah and our dev boxes are configured for in memory storage whereas production is configured to use a database server. Not necessarily a performance issue, but certainly one of concern.

The point here is that a config file should be used for the purpose of making sure the application can execute on that particular platform / machine.