Días de vacaciones, pero sin dejar de revisar información importante. Por ejemplo después de leer  este post en el blog de ScottGu

Don’t run production ASP.NET Applications with debug=”true” enabled

 

One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally (or deliberately) leave the <compilation debug=”true”/> switch on within the application’s web.config file.

 

Doing so causes a number of non-optimal things to happen including:

 

1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)

2) Code can execute slower (since some additional debug paths are enabled)

3) Much more memory is used within the application at runtime

4) Scripts and images downloaded from the WebResources.axd handler are not cached

 

This last point is particularly important, since it means that all client-javascript libraries and static images that are deployed via WebResources.axd will be continually downloaded by clients on each page view request and not cached locally within the browser.  This can slow down the user experience quite a bit for things like Atlas, controls like TreeView/Menu/Validators, and any other third-party control or custom code that deploys client resources.  Note that the reason why these resources are not cached when debug is set to true is so that developers don’t have to continually flush their browser cache and restart it every-time they make a change to a resource handler (our assumption is that when you have debug=true set you are in active development on your site).

 

When <compilation debug=”false”/> is set, the WebResource.axd handler will automatically set a long cache policy on resources retrieved via it – so that the resource is only downloaded once to the client and cached there forever (it will also be cached on any intermediate proxy servers).  If you have Atlas installed for your application, it will also automatically compress the content from the WebResources.axd handler for you when <compilation debug=”false”/> is set – reducing the size of any client-script javascript library or static resource for you (and not requiring you to write any custom code or configure anything within IIS to get it).

 

 

Esta información suena a sentido común, pero se me ocurrió revisar en un server de producción algunos de los web.config de los sitios publicados. Y me encontré con varias sorpresas no muy agradables, obviamente, después de hablar y constatar alguna información con los equipos implicados, corregimos los errores.

Creo que la moraleja de estos minutos de trabajo, es que nunca hay que descartar los puntos de revisión de los aspectos “demasiado obvios” durante el proceso de desarrollo (y más aún al final, jejeje).

Saludos.

El Bruno.

Leave a comment

Discover more from El Bruno

Subscribe now to keep reading and get access to the full archive.

Continue reading