Search code examples
c#.netvisual-studioperformanceproduction-environment

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 practices ?

Thanks for your answers !


Solution

  • 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.