SharePoint 2010:大二进制对象基于磁盘的缓存

friht

　　在SharePoint中一直存在的难题是如果有效的存储比较大的二进制对象，比如图片，声音文件，视频文件等。由于SharePoint的数据基本上都存在SQL数据库中，因此读取和存储这些大的二进制文件，非常影响SharePoint 的性能。能有没有比较好的解决方案呢？本文就分享一下SharePoint
2010 对大二进制对象基于磁盘的缓存的功能。

　　基于磁盘的缓存，当客户端请求这些对象时，就避免了和数据库之间频繁的往返通信，只是在第一次请求对象的时候，从数据库检索到文件，然后将其缓存在web的客户端，并用缓存的数据为后续的请求提供服务。

启用基于磁盘的缓存

　　默认情况下SharePoint禁用了基于磁盘的缓存，若要启用并自定义基于磁盘的缓存，必须修改映射到IIS站点的SharePoint
web应用程序的Web.config文件。




   <BlobCache location="C:\BlobCache\14" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="true" />

在上面的示例中：
　　Location：用于存储缓存文件的目录
　　Path：需要缓存的文件
　　Maxsize：允许缓存文件最大值
　　Max-age：指客户端缓存文件的过期时间，如果缓存自上次下载后尚未过期，如果重新请求该缓存项，不会重新请求。默认是24小时
　　Enabled：启用或者禁用缓存。

对于上面的设置，在本示例中我们唯一需要更改的就是启用基于磁盘的缓存。

查看效果

　　创建一个文档库，上传比较大的图片，第一次请求后，我们来查看磁盘上缓存的文件。由于我们缓存的路径是：C:\BlobCache\14, 我们直接定位到该文件夹，
　　


　　我们看到14文件夹下的目录结构，首先基于磁盘的缓存目录最高一层是Web Application，然后站点，然后是文档库，然后才是文件。
进入相应的文档库就能看到缓存的文件。

强制刷新基于磁盘的缓存
　　给予我们在Web.config中缓存的设置项，我们的缓存24小时内才会过期，因此如果你在24小时内对文件进行了修改的话，用户访问的始终是最初缓存的文件，这就产生了延迟的问题，我们是否有办法刷新基于磁盘的缓存呢？答案是肯定的，但依然做不到实时刷新。

　　我们可以通过网站设置
--> 在网站集管理组里单击“网站对象缓存”，你可以通过里面的设置重置当前服务器或者所有服务器上的缓存。

　　基于磁盘缓存的改进 (微软官方的文档，直接复制过来一边阅读）
Microsoft SharePoint Server 2010 通过增加服务器场容量、增加吞吐量并支持数字媒体资产，为基于磁盘的缓存引入新功能。

基于磁盘的缓存的主要目标是，通过减少 Microsoft SQL Server 的负载来增加服务器场的容量。基于磁盘的缓存通过将文件内容存储到前端 Web 服务器的硬盘中来做到这一点。当未缓存的文件的请求由前端 Web 服务器处理时，基于磁盘的缓存将从 SQL Server 中获取文件，再将该文件保存到磁盘，然后将该文件提供给请求它的客户端。之后，将从存储在磁盘上的文件提供对由前端 Web 服务器处理的同一文件的将来请求，而不是从 SQL Server 提供这些请求。每个前端 Web 服务器都保留自己的缓存。

基于磁盘的缓存还会在访问缓存文件时增加服务器的吞吐量，因为可立即将这些文件提供给客户端，而无需先访问 SQL Server。

基于磁盘的缓存通过提供 HTTP 字节范围支持来支持 SharePoint Server 2010 中的数字资产媒体；基于磁盘的缓存现在可提供针对部分文件的请求。基于磁盘的缓存将在磁盘上对整个文件进行缓存，但对文件的部分内容（如视频的最后 5 MB 内容）提出的请求返回请求的字节数，而不是返回整个文件。仅返回部分文件可节省带宽，更重要的是，可使媒体播放器向基于磁盘的缓存文件发出“搜寻”请求。例如，如果您决定跳到您在 Windows Media Player 上观看的视频的结尾附近，则它会计算您正在搜寻的字节范围并针对所需的字节发出范围请求。

在管理大型文件（如视频和其他富媒体）时，SharePoint Server 2010 需要说明从 SQL Server 获取这些文件需花费较长时间这一事实，从而为客户端造成较长的延迟。为了解决此问题，基于硬盘的缓存将从 SQL Server 上分段下载内容。在基于硬盘的缓存下载完几段内容后，它会开始向客户端发送文件。此方法大大改进了客户端上的“至第一字节的时间”(TTFB) 体验，因为无需先从 SQL Server 接收整个文件，基于磁盘的缓存便可开始提供文件。