因此,在SharePoint博客圈中似乎每个人都只是从其他博客复制并粘贴相同的项目符号。我看到的一个要点是SharePoint网站模板的效率低于网站定义,因为网站定义存储在文件系统中。这是真的吗?
网站模板效率较低似乎很奇怪。我的理解是,无论您使用网站模板还是网站定义,所有网站内容都存在于数据库中。站点模板一次应用于数据库,从那时起,站点不应该关心内容是否是使用站点模板创建的。
那么,网站模板效率低于网站定义的原因是什么?
编辑:指向存在性能差异的博客的链接:
至少,我认为上述文章不完整,我认为根据我对SharePoint架构的了解,有些内容会产生误导。
我读了另一篇反对性能差异的博文,但我找不到链接。
答案 0 :(得分:4)
使用网站模板与网站定义对性能的影响通常被夸大了。
为什么?
好吧,让我们举个例子:
你有什么?好吧,要记住的重要一点是“重影”发生在PAGE级别,而不是在SITE级别。由于您尚未自定义任何页面,因此您访问的任何页面仍直接来自文件系统的站点定义。
想要证明,这是两个测试:
首次测试
第二次测试
它会失败。为什么?因为他们的机器上不存在站点定义。
因此,回到您的问题,“SharePoint网站模板的性能是否真的低于网站定义?”我的答案是:“在您决定使用网站定义或网站模板时,性能考虑不应发挥作用,您应具备的功能目标”。现在它引起了争议,但对我而言,选择网站定义而非创建功能的原因非常少。
就“重影”而言。是的,当定制你的页面将存储在数据库中,并且是的,你将不得不做一个数据库往返来获得它。但是,SharePoint,它是智能的,当然会缓存它。所以,从理论上讲,它的速度较慢,在实践中,没有人真正注意到。
Ghosting自2003年以来一直在该产品中(可能在之前的STS中,不记得了)我从未见过有关性能影响的官方指导,也没有任何人推测超出“它慢”的评论。
这让我相信它并不是真的令人担忧。对“Ghosted”页面的更大担心是维护它们所带来的困难,但是,对于2007和Masterpages,这是一个小得多的问题。
答案 1 :(得分:2)
unghosting的问题并不像升级问题那么严重。
在SPS2003中,unghosting存在性能缺陷。其中大部分问题都在SharePoint 2007中得到解决。首先,SPVirtualPathProvider将非幻影页面作为无编译页面运行 - 这实际上至少为第一页提供了更快的渲染。
真正具有无重影的杀手(或定制 - 曾经认为重命名这个术语并切换“un”的好主意?;-)是你想升级的时候,你的页面,页面布局,母版页,内容类型等都是定制的。如果您曾经尝试过对广泛定制的MOSS网站进行化妆品升级,那么您也知道如何在不丢失自定义页面中包含的布局或功能的情况下让所有内容显示新设计是多么痛苦。
HTH 安德斯拉斯克
答案 2 :(得分:1)
站点定义更高效,因为它们被缓存在文件系统上,模板是否存储在数据库中,每次呈现页面时都必须编译和执行。此外,与基于现有网站模板的模板不同,自定义网站定义是独立升级的。
在this blog post和this updated one中已经很好地概述了其他差异。
答案 3 :(得分:0)
这里的问题叫做鬼影。开箱即用的SharePoint网站在SharePoint网站的12个配置单元中存储了许多文件(包括masterpages和pagelayouts)。当对这些文件发出请求时,SharePoint足够聪明,可以执行磁盘读取操作。
可以“Un-Ghost”这些页面。实质上,创建对存储在SharePoint conent数据库而不是文件系统中的页面的修改。对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