我们有一个Sitecore 6.6实例，用于托管多个站点。它托管在IIS 7.5中。我们开发了跨网站使用的自定义Sitecore子布局和管道。
当在bin文件夹中部署任何dll时，Sitecore站点需要很长时间才能启动（8-10分钟）。但是当重置IIS时，启动时间会缩短（30-40秒）。
与IIS重置相比，应用程序启动时间更适合DLL部署的原因是什么？ 有关改进DLL部署的应用程序启动时间的建议吗？
更新1： DLL部署后的启动时间会影响我们的构建过程，因为它会增加所有环境（DEV，STG，LIVE）中的整体构建部署时间。
w3wp流程的概要分析揭示了两个主要热点：
更新2：按照Vicent建议的部署后，w3wp进程的分析快照显示
的主要热点Sitecore.Web.UI.WebControls.Sublayout.GetUserControl（页）
对内存转储的进一步分析表明，线程正在等待新部署的DLL的JIT编译。
答案 0 :(得分：3)
对我来说，这就像你的问题不是sitecore的启动，而是关机。 复制dll时，filewatcher会检测bin文件夹中的更改（将其写入日志）并尝试关闭sitecore（也记录此项），但是如果sitecore的任务在不同的线程上运行，（索引，发布，计划任务）等等），信号量将等待其他线程正常完成。 这就是为什么当你“杀死”进程而不等待线程完成sitecore快速启动时。 我在我的环境中也有这种行为，所以当我需要快速重启时，我复制dll，等待几秒钟，以便至少sitecore尝试关闭然后我杀死与我的池相关的w3p.exe。我不会建议任何人这样做，但我没有办法“善意”杀死线程......也许有人知道如何“强行关闭......”
答案 1 :(得分：2)
这个blog post by Alex Shyba有一些有趣的指针可以改善Sitecore的启动时间（但如果你在讨论的是实时环境而不是DEV环境，则可能不适用。）
如果你还没有这样做，也可能值得检查你的预取缓存并运行Performance Tuning Guide。
答案 2 :(得分：2)
我以前见过这个问题。它发生在6.5版本上，但从那时起我就没有在发行说明中看到它的修复。
Sitecore支持有一个修补程序 - 它确实与其文件系统观察程序任务有关。您需要随身携带一张票，以获取修补程序或其他信息。
此问题的支持服务单参考号为370593.此修补程序的问题是323775.如果您在支持服务单中提到这一点，它应该会加快一些过程 - 如果确实遇到了与您遇到的问题相同的问题。 / p>