SharePoint 网站模板的效率真的不如网站定义吗？
因此，在 SharePoint 博客圈中，似乎每个人都只是从其他博客复制并粘贴相同的要点。 我看到的一个要点是，SharePoint 网站模板的效率低于网站定义，因为网站定义存储在文件系统上。 真的吗？
网站模板的效率较低似乎很奇怪。 据我了解，所有网站内容都位于数据库中，无论您使用网站模板还是网站定义。 网站模板一旦应用到数据库，从那时起，网站就不应该关心内容是否是使用网站模板创建的。
那么，网站模板的效率低于网站定义的架构原因是什么？
编辑：指向表示存在性能差异的博客的链接：
- 来自 MSDN：由于在数据库中存储模板和从数据库中检索模板的速度很慢，因此站点模板可能会导致性能下降。
- 来自 DevX：但是，SharePoint 中的用户模板可能会导致性能问题，并且可能会导致性能问题。如果您尝试为整个组织创建一组可重用模板，那么这不是最佳方法。
- 来自 IT 足迹：因为在数据库中存储模板和从数据库检索模板的速度很慢，站点模板可能会导致性能下降。 每次呈现页面时都会编译并执行数据库中的模板。
- 来自 品牌化 SharePoint：与 SharePoint 相比，自定义网站定义具有以下优势自定义模板：
- 数据直接存储在网络服务器上，因此性能通常更好。
至少，我认为上述文章并不完整，而且根据我对 SharePoint 架构的了解，我认为其中几篇文章具有误导性。
我读了另一篇博客文章，反对性能差异，但我找不到链接。
So, it seems in the SharePoint blogosphere that everybody just copies and pastes the same bullet points from other blogs. One bullet point I've seen is that SharePoint site templates are less efficient than site definitions because site definitions are stored on the file system. Is that true?
It seems odd that site templates would be less efficient. It's my understanding that all site content lives in a database, whether you use a site template or a site definition. A site template is applied once to the database, and from then on the site should not care if the content was created using a site template or not.
So, what is an architectural reason why a site template would be less efficient than a site definition?
Edit: Links to the blogs that say there is a performance difference:
- From MSDN: Because it is slow to store templates in and retrieve them from the database, site templates can result in slower performance.
- From DevX: However, user templates in SharePoint can lead to performance problems and may not be the best approach if you're trying to create a set of reusable templates for an entire organization.
- From IT Footprint: Because it is slow to store templates in and retrieve them from the database, site templates can result in slower performance. Templates in the database are compiled and executed every time a page is rendered.
- From Branding SharePoint:Custom site definitions hold the following advantages over custom templates:
- Data is stored directly on the Web servers, so performance is typically better.
At a minimum, I think the above articles are incomplete, and I think several are misleading based on what I know of SharePoint's architecture.
I read another blog post that argued against the performance differences, but I can't find the link.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
使用网站模板与网站定义的性能影响通常被夸大了。
为什么？
好吧，让我们举个例子：
你有什么？ 好吧，要记住的重要一点是“重影”发生在页面级别，而不是站点级别。 由于您没有自定义任何页面，因此您访问的任何页面仍然直接来自站点定义，直接来自文件系统。
想要证明这一点，这里有两个测试：
第一个测试
第二次测试
它会失败。 为什么？ 因为他们的机器上不存在站点定义。
那么，回到您的问题：“SharePoint 网站模板的性能真的不如网站定义吗？” 我的回答是：“在您决定使用网站定义或网站模板时，不应考虑性能因素，而应考虑您的功能目标”。 现在它引起了争议，但对我来说，很少有理由选择站点定义而不是创建功能。
就“鬼魂”而言。 是的，定制后您的页面将存储在数据库中，是的，您将必须进行数据库往返才能获取它。 但是，SharePoint 很智能，当然会缓存此内容。 所以，从理论上讲，是的，它的速度较慢，但实际上，没有人真正注意到。
重影自 2003 年以来就已经出现在该产品中（可能在那之前就出现在 STS 中，不记得了），我从未见过关于它对性能影响的官方指南，也没有人在“它速度较慢”的评论之外进行猜测。
这让我相信，这并不是真正值得担心的。 “幽灵”页面更大的担忧是维护它们所带来的困难，但是，对于 2007 和母版页来说，这是一个小得多的问题。
The performance impact of using Site Templates versus Site Definitions is generally overstated.
Why?
Well, lets take this example:
What have you got? Well, the important thing to remember is that "Ghosting" happens at the PAGE level, NOT at the SITE level. Since you have not customised ANY pages, then any pages you access are still coming directly from the Site Definition, directly from the filesystem.
Want to prove it, here are two tests:
First Test
Second Test
It will fail. Why? Because the Site Definition does not exist on their machine.
So, to get back to your question, "Are SharePoint site templates really less performant than site definitions?" my answer would be: "Performance considerations should not play a role in your decision to use a Site Definition or a Site Template, the functional objective you have should be". Now it get controversial, but for me, there are very very few reasons to opt for a Site Definition over creating Features.
As far as "Ghosting" goes. Yup, when customised your page will be stored in the Database, and yup, you will have to do a database round trip to get it. But, SharePoint, smart that it is, will of course cache this. So, in theory, yup its slower, in practice, no one really notices.
Ghosting has been in the product since 2003 (probably in STS before that, dont remember) and I have never seen official guidance on the performance impact it has, nor anyone speculating beyond the "it is slower" comments.
This leads me to believe that it just isn't really worrying about. The bigger worry with "Ghosted" pages is the difficulty that comes with maintaining them, but then, with 2007 and Masterpages this is a much smaller problem.
消除重影问题与其说是性能问题，不如说是升级问题。
在 SPS2003 中，消除重影有一个性能缺陷。 这些问题中的大部分已在 SharePoint 2007 中得到解决。首先，非幻影页面由 SPVirtualPathProvider 作为非编译页面运行 - 这实际上至少为第一页提供了更快的渲染速度。
消除重影（或定制 - 谁曾认为重命名该术语并切换“un”是个好主意？;-）的真正杀手是当您想要升级以及您的页面、页面布局、母版页时、内容类型等都是定制的。 如果您曾经尝试过通过广泛的自定义对 MOSS 网站进行外观升级，您也会知道在不丢失自定义页面中包含的布局或功能的情况下让所有内容都显示新设计是多么痛苦。
哈
安德斯·拉斯克
The issue with unghosting is not as much a performance issue as an upgrade issue.
In SPS2003 unghosting had a performance drawback. Much of these problems was addressed in SharePoint 2007. For one thing, the un-ghosted pages run as no-compile pages by SPVirtualPathProvider -this actually gives a faster rendering at least for the first page.
The real killer with un-ghosting (or customizing -who ever thought it a good idea to both rename the term and also switch the "un"? ;-) is when you want to upgrade, and your pages, page layouts, master pages, content types etc are customized. If you ever tried doing a cosmetic upgrade of a MOSS site with extensive customization, you also know what a pain it is to get everything to show the new design, without loosing the layout or functionality contained in the customized pages.
hth
Anders Rask
站点定义的性能更高，因为它们缓存在文件系统上，无论模板是否存储在数据库中，并且每次呈现页面时都必须编译和执行。 此外，与基于现有网站模板的模板不同，自定义网站定义是独立升级的。
此博客中很好地概述了其他差异帖子和此更新了一个。
Site definitions are more performant because they are cached on the file system, whether templates are stored in the database and have to be compiled and executed every time a page is rendered. Also, custom site definitions are upgrade independent, unlike templates, that are based on an existing site template.
There are other differences nicely outlined in this blog post and this updated one.
这里的问题称为重影。 开箱即用的 SharePoint 网站在 SharePoint 网站的 12 个配置单元中存储许多文件（包括母版页和页面布局）。 当对这些文件发出请求时，SharePoint 足够智能来执行磁盘读取操作。
可以对这些页面进行“Un-Ghost”操作。 本质上，创建对存储在 SharePoint 内容数据库而不是文件系统中的页面的修改。 对非幻影页面的请求将导致数据库往返（从数据库中选择、返回文件的字节等）。 这必然会导致大量的额外工作。 当您谈论数百或数千个用户访问该站点时，此数据库往返就成为性能问题。
因此，频繁使用的网站的 SharePoint 自定义网站定义将希望在 Web 服务器文件系统上存储尽可能多的文件（并将......从其他所有内容中缓存出来）。 站点定义不一定存储在文件系统上，但该过程（除了更加复杂之外）可以更好地控制任何自定义项目的存储位置。
两个博客讨论该问题的示例。
http://itfootprint.wordpress.com /2007/04/18/sharepoint-site-template-vs-site-definition/
http://my.advisor.com/doc/17614
The issue here is called Ghosting. An out of the box SharePoint site stores many files (including masterpages and pagelayouts) in the 12 hive of the SharePoint website. When a request is made for these files, SharePoint is smart enough to do a disk read operation.
It is possible to "Un-Ghost" these pages. Essentially, createing a modification to the page that is stored in the SharePoint conent database instead of the file system. A request for an Un-Ghosted page will result in a database round trip (selecting from the database, returning the bytes of the file etc). This necessarily results in a non-trivial amount of extra work. When you are talking about 100's or 1000's of users hitting the site, this database round trip becomes a performance issue.
So a SharePoint custom site definition for a heavily used website will want to store as many files on the web server file system as possible (and cache the .... out of everything else). A site definition is not necessarily stored on the file system, but the process (aside from being way more complex) gives far more control of the storage location of any customised items.
An example of two blogs talking about the issue.
http://itfootprint.wordpress.com/2007/04/18/sharepoint-site-template-vs-site-definition/
http://my.advisor.com/doc/17614