JeffGonzalez : IScalable

February 2005 - Posts

When a configuration setting makes all the difference

For development/debugging
compilation defaultLanguage="[insert language here]" debug="true" />

For production
<compilation defaultLanguage="[insert language here]" debug="false" />

Compiling in release mod doesn't modify your web.config to make debug=false in this scenario.

Apparently this configuration setting has extensive ramifications in a production environment when using dynamic compilation.

At work we have a scenario where we generate dynamic forms over 4000 clients.  We have a data model that represents each element, group and validation for a particular form.  These dynamic forms are implemented as ascx files with inline code.  So take for example Client0001 has 5 different forms for their website. 

Our directory structure is configured similar to....


Now multiple the number of of folders beneath the Sites directory by 4,000.  A considerable amount of files to say the least.

Setting compilation.debug = true will compile an assembly FOR EACH ascx in a directory as that directory is requested.  Since the code within those ascx files is dynamically compiled is smart enough to NOT compile them until they are needed.

Settings compilation.debug = false will compile an assembly for each directory instead of each file.  We do some load balancing with an F5 Networks BigIp to gain scalability so we would never have 4,000 assemblies loaded in reality.

Let's assume that each webserver handles 300 websites.  With the Compilation.Debug setting set to true the math would be (300 * 5) = 1500 assemblies being loaded.  This is a significant amount of memory being utilitized.  With Compilation.Debug setting set to false the resulting amount of assemblies being loaded drops back down to 300.  HUGE difference.

This is a setting worth looking at.  Microsoft Product Support for teh win!

More Posts