Slow Build of website edit

Slow Build of website Edit

I forbindelse med at vi skal finde en løsning på hvorfor EAJour sitet ofte "builder/ compiler" coden - hvilken resultere en langsomme svar tider for slutbrugerne.

I den forbindelse har jeg fundet ud af hvordan man ser om et site er blevet "build/ compile". Det ses i framework'ets arbejds bibloteker på c:

På min pc:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\eajour10\b389cc87\9fc1d813

Herunder kan man se hvilke dele af sitet der er build'et på hvilke tidspunkter ved at kigge på sidste redigerings dato.

Umiddelbart kan vi ikke finde ud af hvorfor vores site "builder" oftere end de andre site der er kørende på samme server - men vi fandt noget input til at få den til at builde hurtigere.

Citat fra: http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx
Scripts and images downloaded from the WebResources.axd handler are not cached

Det korte og af det lange er. Hvis du i web.config har sat "debug=true" så går du glip af en masse optimering processer som er du vil få fordel af ved at sætte "debug=false".



Vi er gået fra en build tid på omkring 1 minut til omkring 15 sekunder. Altså en mærkbar forbedre.



Nedenstående er en uddybbende forklaring fra bloggen

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