0

We have a Sitecore 6.6 instance which is used to host multiple sites. It is hosted in IIS 7.5. We developed custom Sitecore sublayouts and pipelines which are used across websites.

When any dll is deployed in bin folder, the Sitecore site takes long time to startup (8-10 mins). But when IIS is reset, startup time is less (30-40 seconds).

What could be the reason for application startup time to be more for DLL deployment than IIS Reset ? Any suggestions to improve the application startup time for DLL deployment ?

Update 1: The startup time after DLL deployment impacts our build process as it increases the overall build deployment time in all environments (DEV,STG,LIVE).

Profiling snapshot of w3wp process revealed two major hotspots:

  1. Sitecore.Threading.Semaphore.P
  2. Sitecore.IO.FileWatcher.Worker

Update 2: After following the deployment suggested by Vicent, profiling snapshot of w3wp process revealed major hotspot at

Sitecore.Web.UI.WebControls.Sublayout.GetUserControl(Page)

Further analysis of memory dump showed that thread was waiting for JIT compilation of newly deployed DLL.

nishantagarwal
  • 181
  • 16

3 Answers3

3

For me, it's like your problem is not the start up of sitecore, but the shutdown. When you copy your dll, the filewatcher detects the change in the bin folder (write it to the logs) and tries to shutdown sitecore (log this too), but if sitecore has tasks running on different threads, (indexing, publishing, scheduled tasks, etc), the semaphore will wait until the other threads finish normally. That's why when you "kill" the process without waiting for threads to finish sitecore starts up quickly. I've this behaviour in my environments too, so when i need a quick restart, i copy the dll, wait for a few seconds so at least sitecore tries to shutdown and then and i kill the w3p.exe related to my pool. I won't advice nobody to do this, but i don't have any way to "kindly" kill the threads... Maybe somebody knows how to "force shutdown nicely..."

Vicent Galiana
  • 328
  • 4
  • 15
  • Killing the worker process after DLL deployment reduced the startup time by half. Now it is taking 4-5 mins for startup which is still significantly high. – nishantagarwal Nov 20 '13 at 09:42
  • 1
    Ups... here I go again... So the problem now could be rebuilding your entire site... when you just restart / mill etc, nothing has changed so .NET doesn't need to rebuild, but when you change the dll it does... I just found this [link](http://stackoverflow.com/questions/54929/hidden-features-of-asp-net/1078420#1078420 ) using optimizecompilations=true in the compilation section of the web config. According to this information sound like it could help you [link](http://blogs.msdn.com/b/davidebb/archive/2009/04/15/a-new-flag-to-optimize-asp-net-compilation-behavior.aspx) – Vicent Galiana Nov 20 '13 at 23:31
2

This blog post by Alex Shyba has some interesting pointers to improve the startup time for Sitecore (but might not be applicable if you're talking about a live environment rather than a DEV environment).

It might also be worth checking your prefetch caches and running through the Performance Tuning Guide if you haven't done that yet.

Trayek
  • 4,410
  • 3
  • 24
  • 39
  • we tried reducing prefetch cache but the impact was minimal. Startup time after DLL deployment is still more than app pool recycle/IIS restart. – nishantagarwal Nov 19 '13 at 08:30
2

I've seen this problem before. It happened on version 6.5, but I've not seen a fix for it in the release notes since then.

Sitecore Support has a hotfix for this - it was indeed related to something with their Filesystem watcher tasks. You would need to raise a ticket with them, to get the hotfix or additional information.

My support ticket reference for this issue is 370593. The hotfix has issue 323775. If you mention this in your support ticket, it should speed up the process a bit - if it is indeed the same issue you're experiencing.

Mark Cassidy
  • 5,829
  • 1
  • 22
  • 33