共用方式為

Does SharePoint 2010 support BranchCache?

  • 發行項

 

In a word - yes!   Perhaps you’ve heard how BranchCache in the Windows 7 and Windows Server 2008 R2 operating systems can help increase network responsiveness of applications when accessed from remote offices. Remote offices often can have high-link utilization and poor application responsiveness. BranchCache improves the experience of users in those offices - in some cases as if they were on the local area network. Similar to a content accelerator appliance, BranchCache also helps reduce WAN utilization as documents are cached locally at a 'branch office' - rather than having to round-trip it across an ocean.

 

BranchCache can be configured in two modes….distributed cache(peer-to-peer)  mode or hosted cache mode - for more information on BranchCache and how its configured, check out BranchCache in Windows 7 and Windows Server 2008 R2 Overview

 

BranchCache improves performance of applications that use either HTTP, HTTPS, as well as SMB (the protocol used for shared folders) and WebDav (an extension of HTTP). Because SharePoint uses these  protocols, it is able to take advantage of BranchCache. Just remember that clients must be using Windows 7 and Windows 2008 Server for it to work.

 

But wait...there's more!

 

In addition to BranchCache, there are a number of other improvements in SharePoint 2010 that our customers are taking advantage of for both distributed SharePoint applications as well as disconnected scenarios including Office Data Cache, SharePoint Workspace,  Office Web Applications and more.

 

FSSHTTP and the Office Document Cache***

 

The FSSHTTP protocol comes between the client and the Web Front End - once the file is downloaded to the client for the first time, the FSSHTTP protocol will transfer only differences when the file is saved. The same is true on the file open/read on the second time. This works only when the client machine is using Office2010 and the file format  is Office XML format. You can find your taskbar an icon for the "Upload Center"  - this is the Office Data Cache (ODC) . The upload center will show you which documents are in your local cache, but you rarely have to care.

 

 

 

 

The actual files are kept in your user AppData folder but they are in binary form so this is the best interface should you want to take action on any of these files.

 

So what is the benefit for those remote users? First there is a model-less save experience. You don't have to wait a long time every time you click save. Because we are only transferring differences, there is less wait time and reduced network traffic across the wire. Additionally, having a cached copy can be a benefit if there is an interruption of service or disconnection from the network. Updates to a file will be pending and will be uploaded when a connection is restored.

 

SharePoint Workspace

 

SharePoint Workspace - the evolution of the product formally known as Groove (why does Prince come to mind every time I mention that?)   - has similar benefits to the ODC, however  SharePoint Workspace can take an entire site hierarchy offline including custom lists and line-of-business data. While the most obvious benefit is for disconnected workers, some of our customers are using it exclusively in low-bandwidth situations because they are less affected by network latency and for its ability to synchronize with the SharePoint server in the background. 

 

 

Office Web Applications

 

I had been telling customers for several months about the benefits of Office Web Applications before even having a "dogfood" version to test. "You get an extremely light  payload optimized for browsing, allowing you to view - then do a lightweight edit complete with the Ribbon Fluid UI - enabling a complete roundtrip without opening a client application" I would say. To be honest, I wasn’t thinking this was a big deal, however, now that I am using the Web Apps often working with very large files I now see that it *is* a big deal! Remote users no longer need to download a large document just to review it or for a quick edit. Office in the browser will most often have a faster time-to-first-page than their rich client companion.

 

 

If your using FAST search, you also get the benefit of the Silverlight document previews in search results made possible by the Office Web Applications. This is can be a big time/bandwidth saver by ensuring that the large PowerPoint presentation I'm about to download is the correct one for example.

 

 

 

Mobile Pages

 

While mobile pages are not new, they do provide enhanced functionality and better device support including Blackberry 4.x and Safari/iPhone 3G/S. The default is a text view, there is also an image view that presents the page as a lightweight JPG image, as well as a thumbnail index that allows you to quickly navigate light-weight versions of SharePoint pages. Keep in mind that the mobile pages can be navigated by browsers as well as phones, resulting in reduced network traffic and faster load times on narrow and latent connections.

 

Support for Read-only Farms

 

 

Improvements in log shipping now allow content to be published to one or more remote read-only farms via uninterrupted log shipping. That allows content to be published to one or more locations closer to where remote users would be consuming it and double as a disaster recovery farm by switching the read-only database to read/write. The problem in the past has been the time required for SQL to process the logs in the recovery farm which can take several minutes. What's new in 2010 is the ability for SharePoint to dynamically tell SQL to switch databases via PowerShell.  By having an extra database in the read-only farm, (yes unfortunately you would need to have double the storage) you could switch to a second database while you process logs in the first. This would give you an uninterrupted read-only experience.

 

Hopefully you found even more than what you were hoping for  in improvements in SharePoint 2010 for narrow bandwidth or geographically distributed users!

 

*** Note: BranchCache and the FSSHTTP Protocol are both technologies that offer more responsive experiences for both mobile and branch office workers, however they work independently of each other. That is, in scenarios where the FSHTTP protocol is used - specifically in conversations between Office 2010 and SharePoint Server 2010 - BranchCache is not leveraged. BranchCache works by computing hashes for the body of HTTP responses as they pass through the Windows Server 2008 R2 networking stack. With FSSHTTP, the fields and headers are embedded in XML and contained in the payload of the HTTP conversation. Those fields and headers are what allows a client to retrieve pieces of a document, lock documents, and carry out other operations supported by SharePoint. Now that SharePoint is transporting the embedded XML control information in addition to just document data, it is no longer cacheable as it may change between seemingly identical downloads of the same document or the same document fragment. Again, this applies specifically to Office 2010 and SharePoint Server 2010 only. BranchCache is still leveraged in other scenarios including Office 2010 previewing documents on SharePoint 2010 server, non-office documents, and conversations between SharePoint 2010 and Office 2007 client.

Comments

  • Anonymous
    June 17, 2014
    BranchCache is still leveraged in other scenarios including Office 2010 previewing documents on SharePoint 2010 server, non-office documents, and conversations between SharePoint 2010 and Office 2007 client