Navigate Up
Sign In

The Impact of Shredded Storage on SharePoint 2013

Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.

 

Editor's note: Contributor Trevor Hellebuyck is co-CTO at Metalogix. Follow him @thellebuyck

2013-03-06-ShreddedStorage-01.pngThere is little doubt the SharePoint community is excited for SharePoint 2013. With 60% of users in a recent SharePoint survey saying they want to upgrade in the next year, the anticipation is building to a climax.

One feature that has garnered a lot of buzz, and some confusion, is the new Shredded Storage feature and what impact it will have on binary large objects (BLOBs) storage. In this two-part series, we’ll delve deeper into Shredded Storage, explore its impact on SharePoint 2013 and address the myths about the new feature and Remote BLOB Storage.

Before we plunge into the details it makes sense to define what Shredded Storage is and is not. The term "shredding" has created a lot of confusion. Shredded Storage does not refer to file shredding, which is the secure deletion of files by overwriting the data multiple times. StoragePoint and many other storage-related products include this feature. Instead, SharePoint 2013’s Shredded Storage is an attempt by Microsoft to reduce the I/O impact when saving versions of a document or file by "shredding" it into smaller pieces.

Microsoft developed shredded storage to address an issue that resulted from how document edits or versions are stored in SharePoint and to reduce the number of transaction logs. The result – significantly improved I/O (network and disk) and reduced CPU overhead when storing incremental changes to documents. The SharePoint product team has done a fantastic job addressing what has been a long-standing complaint in the way files are stored in previous versions of SharePoint.

Unfortunately, by addressing one issue, Microsoft introduced another that results in a performance decrease for the uploading and downloading of files in SharePoint.

A Brief History Lesson

With the introduction of SharePoint Team Services and subsequently SharePoint Portal Server 2003, Microsoft moved away from using the Web Storage System and settled on using SQL Server exclusively for the storage of BLOBs. BLOBs are immutable objects when stored in SharePoint. This means that BLOBs are created and deleted but never updated. When editing existing documents in SharePoint, edits result in new BLOBs being created. These new BLOBs are full copies including the edits and not incremental changes.

This means that if you maintain 10 versions of a 1MB document you would end up with approximately 10MB in total storage requirement excluding metadata. While this wasn't the most efficient use of storage it was the simplest way to handle versions without introducing complexity. Unfortunately SharePoint has a tendency to spin off new versions of documents even if only metadata has changed. With the introduction of SharePoint and Office 2010 Microsoft optimized communication between the Office client and the SharePoint server by implementing a file synchronization protocol named Cobalt.

What Does Cobalt Mean?

I am not going to cover Cobalt in nauseating detail as the topic has been covered quite well by Bill Baer in his post about Shredded Storage. What you should know is that Cobalt allowed the Office client to send incremental changes rather than the entire file to the server when a document was saved. The incremental changes were then reassembled on the server and saved as a complete file. Shredded Storage in SharePoint 2013 extends the saving of incremental changes to the database where only file changes are stored rather than entire copies of the file.

The goal of Cobalt and subsequently Shredded Storage is to reduce the network bandwidth utilization (client changes sent to the SharePoint server) and the I/O operations (SharePoint Server sends file to database) that result from incremental changes to documents. In fact Shredded Storage significantly improves I/O operations while reducing CPU overhead when saving incremental changes to documents. What isn't immediately apparent is the negative impact to I/O operations for the inserting of new files and downloading of existing files.

The Test Results

Our test results (see full table here) compared SharePoint 2010 and SharePoint 2013 upload and download times on the same document set. Our lab testing confirms that SharePoint 2013 uploads and downloads are slower — and in some cases significantly slower — than SharePoint 2010. This is a direct result of Shredded Storage. The overhead involved in determining how to split a document into smaller pieces and store those smaller pieces definitely has an impact on the performance for uploads and downloads.

One Size Does Not Fit All

The test results led us to examine the configuration options for Shredded Storage to determine if we could mitigate the negative impact on uploads and downloads. Unfortunately your options are limited. Contrary to other blog posts on the topic, Shredded Storage cannot be disabled. You actually had the option to disable shredding in the SharePoint 2013 beta but that option was eliminated in the RTM build. The only remaining option is changing the default shred or "chunk" size that files will split into when they are stored.

For me, the decision to disable shredding is a bit nearsighted. Not all organizations use SharePoint for document collaboration where content is being updated/edited in large quantities. I would even argue that while some organizations do have collaboration sites where lots of editing occurs, they almost certainly have other sites where documents are simply uploaded and downloaded without edits or new versions being created.

A common example is document imaging where PDF/TIFF images are stored within SharePoint. Those images never change. Or, how about a document center that contains tens of thousands of published documents that are being read rather than updated? What's more, Shredded Storage provides little value. It is true that even with versioning disabled the I/O between the client, SharePoint Server, and database Server will be optimized. However you will not reduce overall storage requirements.

Unfortunately you are relegated to living with Shredded Storage in hopes that Microsoft will provide, at a minimum the ability to disable the feature. An even better would be an option to control Shredded Storage at the site or site collection level for added flexibility.

Solving one problem by introducing another significant problem is going to make for some unhappy campers who are already struggling to keep up with the explosive growth of their SharePoint content.

Categories: SPF 2013; Performance and Optimization; Management

Comments

Wahid Saleemi

Great insight

Thanks for the article Trevor, this is great insight into side effects of shredded storage.

Posted 08-Mar-2013 by Wahid Saleemi
Markus Hintner

Turn off shredded storage

Hi,
you can turn off shredded storage on a per-web-application Basis:
$wa=Get-SPWebApplication http://<URL>
$wa.WebService.FileOperationSettings = 2
$wa.WebService.Update()
FileOperationSettings: 1 = enable, 2 = disable
AlwaysDirectToShredded = 1
NeverDirectToShredded = 2
ChunkSize (default 64KB)
$wa.WebService.FileReadChunkSize
$wa.WebService.FileWriteChunkSize
 
Cheers
Markus

Posted 10-Mar-2013 by Markus Hintner
Trevor Hellebuyck

Turn Off Shredded Storage

Markus,
 
Unfortunate the script to disable shredded storage does not work in the RTM build.  It was a feature that Microsoft enabled in the beta build but then disabled in the RTM build.  The only way to control shredded storage is by adjusting the chunk size.  You can effectively disable shredded storage by setting the chunk size to 2GB.  Here is a sample script for changing the chunk size.
 
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$service.FileWriteChunkSize = chunk size in bytes
$service.Update()

Posted 19-Mar-2013 by Trevor Hellebuyck
Natan Abramovich

Great article!

It seems that MS largely implemented shredded storage to improve their own performance with SharePoint Online. If you deploy it locally, you may not even need shredded storage in the first place. Furthermore, if you want to achieve space saving, de-duplication on the hardware level is a good idea.

Posted 17-May-2013 by Natan Abramovich
distro online terpercaya

Howdy

Howdy, i read your blog occasionally and i own a similar one and i was just wondering if you get a lot of spam comments? If so how do you prevent it, any plugin or anything you can advise? jaket kulit pria | jaket jeans pria

Posted 12-Dec-2013 by distro online terpercaya

Notify me of comments to this article

E-mail:
   

Add Comment

Title:

 
Comment:
Email:

   


Name:

 
Url: