RSS

Monthly Archives: 九月 2007

新工具:表单/Cookie 验证网站爬网设置工具

在今年3月份的blog里面,我曾经说过SharePoint Team将会发布一个补丁来让SharePoint Server 2007的搜索引擎支持对基于表单/Cookie验证的网站进行爬网。今天,SharePoint Team正式发布了SharePoint Server 2007 Tool: Add/Edit Crawl Rules with Form/Cookie Credentials。在下载页的说明中有使用方法的介绍。

 

Posted by on 2007/09/26 in 未分类

58 Comments

Tags:

SharePoint 2007 Web Content Management 性能优化系列 3 – IIS压缩

IIS压缩并不是一项新技术,但对于SharePoint站点而言,IIS压缩能起到很大的作用。在IIS服务器上启用IIS压缩功能之后,在IIS服务器把页面内容发送给浏览器之前,会在服务器上先把内容进行压缩,然后发送压缩后的数据,浏览器接收到数据后,会自动进行解压,然后显示。由于在网络上传输的数据被压缩了,所以可以将页面内容更快的传送到浏览器,提高页面浏览速度。

虽然IIS服务器上对页面内容进行压缩会耗费一定的CPU时间,但这对于现在主流服务器CPU而言,已经不会造成什么问题。而且这点CPU时间与节省的数据传输时间相比,实在是太划算了。每次压缩过一个页面之后,IIS会将压缩后的文件缓存到磁盘上,这样可以避免下次再重复压缩。

在IIS服务器上启用IIS压缩虽然可以通过图形界面的IIS管理器完成,但有些配置仅仅通过IIS管理器是做不了的,所以,我们使用IIS的一个脚本工具来进行所有的管理和配置。下面的指令需要在服务器上的命令提示符中执行。

在IIS服务器上启用静态文件(.js、.css、.html之类)压缩:
cscript C:\Inetpub\adminscripts\adsutil.vbs set w3svc/filters/compression/parameters/HcDoStaticCompression true

在IIS服务器上启用动态文件(.asp之类)压缩:
cscript C:\Inetpub\adminscripts\adsutil.vbs set w3svc/filters/compression/parameters/HcDoDynamicCompression true

在动态文件压缩中添加“.aspx”文件类型(SharePoint站点所有页面都是.aspx的),要执行两条指令:
cscript C:\Inetpub\adminscripts\adsutil.vbs SET W3SVC/Filters/Compression/Deflate/HcScriptFileExtensions “asp” “dll” “exe” “aspx”
cscript C:\Inetpub\adminscripts\adsutil.vbs SET W3SVC/Filters/Compression/gzip/HcScriptFileExtensions “asp” “dll” “exe” “aspx”

将默认的压缩率提高,也是两条指令:
cscript C:\Inetpub\adminscripts\adsutil.vbs SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel “9”
cscript C:\Inetpub\adminscripts\adsutil.vbs SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel “9”

启用IIS压缩后,到底能为我们节省多少数据传输呢?我们可以简单的测试一下。我们使用Microsoft Fiddle,这个好用且强大的工具。它原理上是一个代理,能让浏览器通过它去获取HTTP内容,它则自动记录浏览器的访问历史数据。Fiddle可以在http://www.fiddlertool.com/fiddler/version.asp下载。

首先,关闭IIS压缩,清空浏览器缓存,然后在IE中访问MOSS 2007的默认站点首页,在Fiddle中记录下的访问历史数据如下:

Request Count:     29
Bytes Sent:     11,089
Bytes Received: 676,934

这些信息表示,浏览器一共请求了29项资源,服务器一共向浏览器发送了676K数据。676K!这仅仅是默认的MOSS 2007站点首页哦!

然后打开IIS压缩功能,再清空浏览器缓存,再次访问一下首页,Fiddle中记录的信息如下:

Request Count:     29
Bytes Sent:     11,089
Bytes Received: 230,276

可以看到,仅仅通过简单的启用IIS压缩功能,MOSS 2007的默认首页所请求的数据大小就从676K减少到了230K。

 

Posted by on 2007/09/21 in 未分类

51 Comments

SharePoint 2007 Web Content Management 性能优化系列 2 – 32 bits or 64 bits ?

从我的观点来说,64-bits的好处,在现阶段而言,在服务器上的体现更有现实意义。64-bits的硬件上早已经不是问题了,甚至连我现在使用的Centrino Duo笔记本都支持x64架构(虽然我仍然是安装的32-bits Windows Vista)。

64-bits的第一大好处就是支持更多的内存,32-bits的寻址空间不能大于4G(而且由于现在的Windows使用了直接内存访问技术,比如,Windows会将显卡的显存映射成高位的内存地址,通过“模拟的”往内存地址写数据,就能实现更方便的访问显存,所以,一些高位的内存地址已经被占用了,而不能将4G内存地址全部给真正的内存),而64-bits完全没有这个限制。在数据库这样对内存敏感的场合,64-bits将带来很大的优势!

对于SharePoint而言,它自己,以及它所依赖的组件,都有64-bits版本,包括Windows Server 2003、SQL Server 2005、.NET Framework 2.0 & 3.0。所以,SharePoint 2007对64-bits有非常好的支持。对于64-bits SharePoint 2007,在安装、配置上和32-bits没有什么区别。

但是如果安装SharePoint 2007的64-bits版本,你也需要有一些注意的地方。首先,不支持将已有的32-bits SharePoint服务器场升级到64-bits上。如果你希望进行一次这样的迁移,需要先进行备份,然后再恢复到64-bits SharePoint上。

对于SharePoint服务器场中的Application Server而言,使用64-bits还有其他一些需要注意的地方。比如,对于Index Server而言,它是使用iFilter组件来对文档进行全文检索,但是iFilter是分32-bits和64-bits的。为了SharePoint能够对PDF文档进行文件检索,我们需要在服务器上安装PDF iFilter,但Adobe并没有发布官方的64-bits PDF iFilter。(倒是有第三方发布过64-bits的PDF iFilter:http://www.foxitsoftware.com/pdf/ifilter/index.html#downifilter

SharePoint 2007服务器场还支持32-bits和64-bits的混合部署。一个比较推荐的方式就是,对于SharePoint的前端Web服务器和应用服务器仍然使用32-bits的SharePoint,但是对于数据库服务器,则单独使用64-bits,这样可以让SQL Server 2005充分享受大内存的好处。

 

Posted by on 2007/09/20 in 未分类

42 Comments

Tags:

SharePoint 2007 Web Content Management 性能优化系列 1 – 做好拓扑架构规划

是的,你可能有些意外,但如果希望你的SharePoint WCM应用有好的性能,第一个要做的,就是在正式开始动手前,好好规划一下整个服务器场的拓扑结构。

SharePoint 2007支持服务器场部署,我们可以将前端Web服务器、应用服务器(包括Index服务器、Query服务器、文档转换服务器、Excel Services服务器等)和数据库服务器分开部署。最小的服务器场规模,可以将所有服务器角色安装到一台物理服务器上,而对于大型应用而言,将各个服务器角色分开部署到单独的物理服务器上,确实可以大大的提高服务器场的响应速度。

微软发布过两个针对SharePoint WCM的解决方案,它们是Visio格式文件,里面包含了解决方案的描述、需要考虑的问题、推荐的实现方式等等。第一个是针对不常更新Web内容的WCM应用,另外一个是针对经常更新Web内容的WCM应用。我建议您在开始之前,好好看看这两个Visio文件。

我个人的推荐部署拓扑方案:
(1)、不要将域控器(Domain Controller)与任何SharePoint服务器安装在一起,这是一种既没有必要、也不方便维护的方法。
(2)、尽量将数据库服务器单独安装到一台物理服务器上,给数据库服务器大一点的内存,SQL Server 2005能够充分的享受大内存的好处,由于SharePoint会将所有数据存放到数据库中,所以好的磁盘IO可以很大的提高数据存取速度,同时RAID-1对于SharePoint数据安全也是很有必要的。如果数据量非常大,那么就要考虑使用多台数据库服务器,给一个Web Application配置多个Content Database,将各个Content Database分布到不同的物理服务器上。
(3)、尽量将应用服务器与前端Web服务器分开到单独的物理服务器上。如果SharePoint中有大量的文档和数据,Index服务是很耗费CPU资源的,所以将Index和Query服务器部署到一台单独的物理服务器上是一个不错的选择。
(4)、对于前端Web服务器,仔细考虑一下,是否有必要使用多台前端Web服务器(也就是说,如果有必要,那就添加一个新的前端Web服务器。怎样才算是有必要呢?我的建议是,在实际环境中亲自体验和测试一下站点的访问速度,比如,使用一些网站压力测试工具来模拟多用户并发访问。任何事先的估算都只是“估计”而已。)。由于SharePoint对服务器场部署的良好支持,我们可以随时将一台新的前端Web服务器添加到整个SharePoint服务器场中,而且SharePoint会自动帮我们在这台新的前端Web服务器上配置IIS站点等,极大的简化了管理员的负担。

关于向SharePoint服务器场中添加新的前端Web服务器,请参考http://technet2.microsoft.com/Office/en-us/library/b4279ff9-2842-475a-8d7f-cc90711c47271033.mspx?mfr=true

总结来说,前端Web服务器:应用服务器:数据库服务器使用1:1:1在很多场合都够用了,如果是2:1:1则更好。

image

要提醒的是,如果在服务器场中有多台前端Web服务器,SharePoint自己是不会自动做访问请求分发的,我们要么需要使用一个NLB设备要做请求分发(推荐的方式),要么使用Windows Server自带的NLB功能来实现。不过好消息是,由于SharePoint不会在前端Web服务器上保存任何访问状态信息(比如Session),所以NLB非常简单,我们可以把任意请求分发到任意前端Web服务器上(也就是说,当一个用户第一次打开页面时,NLB将他的请求分发到Web服务器A,用户点击了页面上的一个按钮触发页面刷新,NLB可能将他的请求分发到Web服务器B,由于SharePoint应用不依赖Web服务器上保存的状态信息,所以这是没问题的),而不用关注访问绑定问题。这确实是SharePoint在设计上的一个大亮点!

关于服务器的硬件,要知道,硬件是很便宜的,有些时候吝惜好的硬件投入只会带来更多的麻烦。下面的微软推荐的硬件配置:

(1)、数据库服务器:双CPU(主频不低于2.5G),4GB RAM(64位系统可以支持更多的内存),SCSI,RAID-1
(2)、应用服务器(Index、Query、Excel Services、Document Conventer):双CPU(主频不低于2.5G),4GB RAM
(3)、前端Web服务器:双CPU(主频不低于3G),>2GB RAM

当然了,并不是说你非得要有上面所说的这些硬件,才能开始玩SharePoint。有时候在真实项目中由于设备所限,我们甚至要将所有东东都安装到一台物理服务器上。我的建议是,如果服务器数量很少,那么内存一定不能低于3GB,然后要有一个双核CPU。

 

Posted by on 2007/09/19 in 未分类

56 Comments

SharePoint 2007 Web Content Management 性能优化系列 前言

相信已经有不少SharePoint Developer正在基于SharePoint 2007构建Web Content Management(WCM)应用。我们先来明确一下什么是WCM应用,典型的WCM应用就是信息发布、新闻发布,通过一个或多个定制的页面模板,大量的发布新的页面。我们经常浏览的Internet上的新闻站点,就是一个典型的WCM应用。

这个系列并不是讲述如何使用SharePoint 2007来构建WCM应用,而是专注在性能上。对于正在进行WCM项目的Developer而言,性能是一个非常大的挑战。我希望这个系列的文章,能够在一定程度上帮到大家。

 

Posted by on 2007/09/19 in 未分类

47 Comments

Tags:

Property Bags Object Model中的小“陷阱”

今天在调试一个SharePoint程序的时候,发现一个Bug。SharePoint 2007中对SPWeb、SPFolder、SPListItem都提供了一个方便的Property Bags特性,用来存放一些自定义的属性信息,就像这样:

SPListItem item = …;
item.Properties[“MyProp1″] = “PropValue1″;
item.Properties[“MyProp2″] = “PropValue2″;
item.Update();

我发现的Bug是,有一些存放在SPWeb.Properties中的自定义属性,没有正确的保存到Content Database中。仔细检查了一下,发现了原因所在。这个小问题确实容易成为一个代码中的“陷阱”,所以提醒一下大家。

SPFolder、SPListItem的Property Bags(即SPFolder.Properties / SPListItem.Properties)都是直接使用一个Hashtable来实现的,当我们调用SPFolder.Update()或SPListItem.Update()时,就能把它们的Property Bags里面的数据也写回到Content Database。

但是,SPWeb.Properties是通过一个定制的SPPropertyBag类(继承自System.Collections.Specialized.StringDictionary)来实现的,通过调用SPWeb.Update()并不会将Property Bags中的数据写回到Content Database,而是需要调用SPPropertyBag.Update()方法。示例:

SPWeb web = SPContext.Current.Web;
web.Properties[“MyProp1″] = “PropValue1″;
web.Properties.Update();

我不知道为什么它们有这样的设计区别,但个人猜测最大的可能,是SPFolder/SPListItem和SPWeb的实现不是一个Developer写的,写SPFolder/SPListItem的Developer想了一下,觉得使用一个简单的Hashtable就足够了,而写SPWeb的Developer则觉得应该专门定义一个SPPropertyBag类,这样整个项目中不同的需要使用Property Bags特性的类都可以重用这个SPPropertyBag。可惜,就像那句老话说的:“开发人员精心设计用来重用的东东,90%的可能都不会有被重用的可能”… :)

 

Posted by on 2007/09/19 in 未分类

2 Comments

Tags:

SharePoint 补丁

Windows SharePoint Services 3.0前几天发布了一个公开的更新补丁,KB941422补丁说明)。虽然WSS Team实际上在不断的制作一些更新补丁,但通常这些补丁只会提供给微软的售后支持部门,而不会每个更新补丁都公开发布。

实际上,对于这样的更新补丁,如果在您的SharePoint服务器上没有发现什么特别重要的问题,并且你确认安装了这个补丁后能够修正那个问题,那么可以暂缓安装这些更新补丁。即使您真的想安装,我也强烈建议在安装补丁之前将站点集内容进行完整备份,以防万一。

现在讲讲我之前干过的一件很白痴的事。我们部门有一台SharePoint服务器,我在安装的时候,是使用我自己在公司域里面的帐号(当然,我在公司域里面的帐号并非域管理员)。由于公司域策略要求我每过一段时间,就必须更改我的帐号密码,所以在我更改了自己的域帐号密码之后,就必须登录到SharePoint服务器上,把SharePoint中涉及到的我的帐号密码全部进行更新(IIS应用程序池、Windows NT Services、SharePoint爬网帐号…等等)。由于我天生懒惰,所以每次在更改了域帐号密码之后,登录到SharePoint服务器上进行密码更改时,我并没有仔细检查是否所有需要改的地方都改到了,而只是随便改几个地方,然后验证管理中心和站点能打开,就匆匆退出了事。

SharePoint服务器忍了我很久之后,终于逮到了我安装一个SharePoint更新补丁的机会,很爽的折磨了我一把。在安装SharePoint更新补丁之后,需要重新运行SharePoint安装配置向导,由它来完成一个升级的过程。但是终于有一次,在我安装完了一个补丁,然后运行SharePoint安装配置向导的时候,它告诉我,“配置失败”!

运行SharePoint安装配置向导失败就意味着SharePoint前端服务器最终不会和后端的配置数据库连接(即使安装一个更新补丁后的再次运行失败,也会导致这个后果),也就是说,所有SharePoint站点,包括管理中心,都无法打开了…

按照“惯例”,我重新启动了服务器,然后重新尝试运行SharePoint安装配置向导,错误依旧,“配置失败”。这次,我打开了升级日志,仔细查看了失败的原因,日志里面显示,是由于一个Windows服务“SPSearch”安装失败造成的。“SPSearch”就是“Windows SharePoint Services Search”服务,它为WSS提供索引和搜索服务。我打开Windows Server管理工具里面的Windows服务管理,找到这个“SPSearch”服务,发现它的状态是“禁用”,我将它的状态改为“手动”,然后尝试直接启动这个服务,但系统直接告诉我,由于登录帐号信息错误,无法启动服务。这个错误通常是因为用来运行服务的Windows帐号错误,或者密码错误。这个服务的运行帐号就是我自己的域帐号,我手工将“SPSearch”服务的登录帐号密码改成正确的密码,然后再启动服务,成功了(是这个服务成功启动了,而不是SharePoint成功恢复正常了)。

到这里,我大致了解了发生这个错误的原因:某一次,在我更改了自己域帐号的密码之后,在登录到SharePoint服务器上更改服务器上我的帐号信息的时候,没有将进行SharePoint索引服务(爬网服务)的帐号密码更改成最新的密码。这个结果在当时应该只是使SharePoint爬网不正常,但一时看不出来,毕竟SharePoint网站和管理中心都能够正常访问,所以我根本没有注意到。但是在重新运行SharePoint安装配置向导时,这个向导会从某个地方(应该是配置数据库)中获取到当前服务器场中的爬网帐号和密码(已过期的错误密码),然后尝试用这个帐号和密码信息重新安装“SPSearch”服务,显然,结果会是失败。

了解了引起错误的原因是一回事,但是修正这个错误确实另外一回事。虽然我已经大致知道了原因,但现在我没有任何途径可以将保存在配置数据库中的爬网帐号和密码更新成最新的正确的信息。手工打开配置数据库,找到这个数据项,然后改掉?我不是没有尝试过,但是…建议你自己打开SharePoint配置数据库看一下里面存储的信息的结果,就知道为什么这么做不太可行了。

现在的我被逼入了绝境,我必须尽快恢复这个SharePoint网站的正常运行,否则俺可爱的部门同事会用口水淹没俺…于是,俺:

1、打开记事本,输入我的域帐号的当前密码,然后将它复制到剪贴板上(为了后面的步骤不需要手工再敲密码,以尽可能提高速度);
2、打开SharePoint服务器上的命令提示符,定位到“Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN”目录;
3、在命令提示符中输入“PSCONFIG -cmd upgrade -force”,这时开始执行SharePoint升级过程;
4、打开Windows Server上的服务管理器,找到“SPSearch”服务,疯狂的按F5,检查“SPSearch”服务的状态;
5、如果发现“SPSearch”服务的状态有变化(由已启动变成停止状态),就表示“PSCONFIG”程序正在重新安装这个服务,用最快的速度打开“SPSearch”服务的属性,在登录帐号的密码处进行粘贴,将我的域帐号最新密码粘贴进去,同时点击“确定”;
6、继续疯狂按F5,监视“SPSearch”服务的状态,循环执行步骤6的动作,直到到达步骤7;
7、命令提示符中提示“PSCONFIG”指令执行完毕,SharePoint成功完成了升级过程;
8、输入“PSCONFIG -cmd configdb -server DBSERVER -database SharePoint_Config -user DOMAIN\USER -password PASSWORD”,将SharePoint Front-end服务器连接到配置数据库;
9、搞定!

凭着俺超强的RP,终于恢复了SharePoint站点的正常运行。

总结:如果你觉得自己运气通常不怎么好(仔细反思一下自己过去几十年的RP),那么在安装SharePoint更新补丁之前,一定要记得对站点集的内容进行备份,这样,你就永远有路可退(大不了熬夜重装,是吧?)。

 

Posted by on 2007/09/11 in 未分类

65 Comments

Tags: