Long initialization time after app pool recycle

Topics: Troubleshooting
Aug 9, 2011 at 4:44 PM


When an app pool thread gets recycled for a C1 website hosted on an IIS 6 system the initialization code for C1 is taking almost a whole minute to complete.


With verbose turned on for logging from start to finish of all initialization code I am getting the below times.


Start: 11:03:36.1652



A big chunk of this time looks like it is the building of the static and dynamic types which have not changed and therefore I don't feel the need to have rebuilt.


Can anyone better help me understand what is going on?


Is there a way I can better control what the build manager does?




Aug 9, 2011 at 6:32 PM

Hi Peter

Looks like assembly cache is broken, and therefore you have all the compilations on every start-up. We are aware that those kind of situations appear and currently working on fixing that problem. Until a permanent fix is ready, you can try to perform the steps described here to solve the performance issue

Aug 9, 2011 at 8:08 PM
Edited Aug 9, 2011 at 8:30 PM

Can you help me understand the function of the assembly cache?  I am confused by the relationship between the composite.generated.dll and what is ending up getting created in the assembly cache.


Aug 10, 2011 at 11:29 AM
Edited Aug 10, 2011 at 11:41 AM

The assembly cache is use for 'short lived assemblies' - they get compiled on the fly and are absorbed by the running process. Typically of a wrapper class, serializer etc. is needed (and is not already available), they get compiled in the assembly cache and then used.

When the process shuts down, all generated code is rolled up and compiled to Composite.Generated.dll which is copied to ~/bin so the next process to launch will have all the generated classes precompiled. Also the pressense in ~/bin will allow the ASP.NET process to see the types (enabling you to reference them from ~/App_Code etc.) and it will also make VS2010 pick it up and give you intellisense.

The problem with our approach have so far been that - if something fall out of place in the cache folder - the Composite.Generated.dll generation fail, and the system has to "catch up" compile wise each time it start and that can take a very long time. Typically this can be fixed by cleaning up the cache and have all code files there regenerated.

We (Martin) are currently changing the way Composite.Generated.dll gets created; we stop using the cached code files - instead we do the entire code generation and compilation of all interfaces, helper classes etc. in one go. This should fix our cache corruption issue once and for all and we also hope this will make the system faster since a lot of small compilations we currently do ad hoc will be done in one bulk compilation.  The costly part of doing compiles seems to be invoking csc.exe and doing linking to a lot of tmp dll's and the strategy we are implementing should reduce the csc.exe invokes a lot and also reduce disk access to reference temporary dll's from the cache.

We still need to also support ad hoc compiles so it is not a super trivial task, but Martin reports this are looking bright and will make the release.

Aug 10, 2011 at 2:03 PM

Thank you for helping me understand.