SharePoint 网站模板的效率真的低于网站定义吗？

Question

因此，在 SharePoint 博客圈中，似乎每个人都只是从其他博客复制和粘贴相同的要点。我看到的一个要点是，SharePoint 网站模板的效率低于网站定义，因为网站定义存储在文件系统中。这是真的吗？

网站模板效率较低似乎很奇怪。据我了解，所有网站内容都存在于数据库中，无论您使用的是网站模板还是网站定义。站点模板只应用于数据库一次，从那时起站点就不再关心内容是否使用站点模板创建。

那么，网站模板效率低于网站定义的架构原因是什么？

---

编辑：表示存在性能差异的博客链接：

• 来自MSDN：由于在数据库中存储和检索模板的速度很慢，因此站点模板可能会导致性能下降。
• 来自DevX：但是，SharePoint 中的用户模板可能会导致性能问题，如果您尝试为整个组织创建一组可重复使用的模板，这可能不是最佳方法。
• 来自IT Footprint：因为将模板存储在数据库中并从数据库中检索它们的速度很慢，所以站点模板可能会导致性能下降。每次呈现页面时都会编译和执行数据库中的模板。
• 来自Branding SharePoint：与自定义模板相比，自定义站点定义具有以下优势：
  • 数据直接存储在 Web 服务器上，因此性能通常更好。

至少，我认为上述文章是不完整的，并且根据我对 SharePoint 架构的了解，我认为其中有几篇具有误导性。

我阅读了另一篇反对性能差异的博客文章，但我找不到链接。

Answer 1

使用站点模板与站点定义的性能影响通常被夸大了。

为什么？

好吧，让我们举个例子：

1. 您采用团队网站网站定义。
2. 您将其另存为新站点模板
3. 然后您可以根据这个新网站模板创建一个新的子网站。

你有什么？嗯，要记住的重要一点是“重影”发生在 PAGE 级别，而不是 SITE 级别。由于您没有自定义任何页面，因此您访问的任何页面仍然直接来自站点定义，直接来自文件系统。

想证明一下，这里有两个测试：

第一次测试

1. 尝试修改原始站点定义中的 default.aspx 页面。
2. 检查您的网站模板，注意您看到了修改。
3. 对文件系统来说仍然是“幻影”

第二次测试

1. 创建新的网站定义。
2. 根据这个新站点定义创建一个新站点。
3. 创建新站点模板
4. 将网站模板发送给使用 SharePoint 的伙伴，并要求他们基于它创建一个新的子网站。

它会失败。为什么？因为站点定义在他们的机器上不存在。

那么，回到您的问题，“SharePoint 网站模板的性能真的不如网站定义吗？”我的回答是：“性能考虑不应在您决定使用站点定义或站点模板时发挥作用，您的功能目标应该是”。现在它引起了争议，但对我来说，选择站点定义而不是创建功能的理由非常少。

就“重影”而言。是的，当定制您的页面时，您的页面将存储在数据库中，是的，您必须进行数据库往返才能获得它。但是，SharePoint 很聪明，当然会缓存它。所以，从理论上讲，是的，它的速度较慢，在实践中，没有人真正注意到。

自 2003 年以来，产品中一直存在重影（可能在那之前的 STS 中，不记得了），我从未见过有关其性能影响的官方指导，也没有人猜测“它更慢”的 cmets。

这让我相信它并不是真的担心。 “幻影”页面更大的担忧是维护它们带来的困难，但对于 2007 和 Masterpages，这是一个小得多的问题。

Answer 2

取消主机的问题与其说是性能问题，不如说是升级问题。

在 SPS2003 中，取消重影存在性能缺陷。这些问题中的大部分已在 SharePoint 2007 中得到解决。一方面，SPVirtualPathProvider 将非镜像页面作为非编译页面运行 - 这实际上至少为第一页提供了更快的呈现速度。

真正的杀手锏（或自定义 - 谁曾认为重命名术语并切换“un”是个好主意？;-) 是您想要升级的时候，以及您的页面、页面布局、母版页、内容类型等都是自定义的。如果您曾尝试通过大量自定义对 MOSS 网站进行外观升级，那么您也知道在不丢失自定义页面中包含的布局或功能的情况下让所有内容都显示新设计是多么痛苦。

hth 安德斯拉斯克

Answer 3

站点定义的性能更高，因为它们缓存在文件系统中，无论模板是否存储在数据库中，并且每次呈现页面时都必须编译和执行。此外，与基于现有网站模板的模板不同，自定义网站定义独立于升级。

this blog post 和 this updated one 中很好地概述了其他差异。

Answer 4

这里的问题称为重影。开箱即用的 SharePoint 网站在 SharePoint 网站的 12 个配置单元中存储了许多文件（包括母版页和页面布局）。当对这些文件发出请求时，SharePoint 足够智能，可以执行磁盘读取操作。

可以“取消幽灵”这些页面。本质上，创建对存储在 SharePoint 内容数据库而不是文件系统中的页面的修改。对 Un-Ghosted 页面的请求将导致数据库往返（从数据库中选择，返回文件的字节等）。这必然会导致大量的额外工作。当您谈到有 100 或 1000 名用户访问网站时，这种数据库往返就成为了性能问题。

因此，对于一个频繁使用的网站，SharePoint 自定义网站定义将希望在 Web 服务器文件系统上存储尽可能多的文件（并将 .... 缓存在其他所有内容之外）。站点定义不一定存储在文件系统中，但该过程（除了更复杂之外）可以更好地控制任何自定义项目的存储位置。

两个博客讨论这个问题的例子。 http://itfootprint.wordpress.com/2007/04/18/sharepoint-site-template-vs-site-definition/ http://my.advisor.com/doc/17614