Tag: BLOB

Fix For Bit Rate Throttling W3WP Crashes

Over the Summer, we dove deep in to SharePoint 2010 for WCM when we re-launched our corporate website. As I mentioned the other day, I spent a decent amount of time looking at caching and some of the new supporting technologies, like Bit Rate Throttling, an IIS.NET extension to IIS 7.x – part of the IIS Media Services 3.0. package that also includes Smooth Streaming. Bit Rate Throttling is like when you watch a YouTube clip and it only buffers a short time in advance of what you’re watching, also known as Progressive Download. In Microsoft’s words, Bit Rate Throttling is…

“…an IIS 7.0 extension that meters the download speeds of media file types and data between a server and a client computer. The encoded bit rates of media file types such as Windows Media Video (WMV), MPEG-4 (MP4), and Adobe Flash Video, are automatically detected, and the rate at which those files are delivered to the client over HTTP are controlled according to the Bit Rate Throttling configuration.”

It basically saves you bandwidth by only transferring what you’ve watched plus a small, configurable buffer. Think about each user that starts watching a ten minute video but only watches one minute. In that time, they may have downloaded five minutes of content – quadrupling the bandwidth consumption unnecessarily. Bit Rate Throttling shares some user experience characteristics with Streaming Media, but it works on a normal web server over HTTP. It’s really quite a simple tool and I won’t devote space here to explaining it when the IIS.NET site already has some great content, including a brief introductory video. Definitely check it out.

So why am I writing about it?

Continue reading “Fix For Bit Rate Throttling W3WP Crashes”

BLOB Cache, HTTP 304 Results and F5/Refresh

A few months ago we launched a new website on SharePoint 2010. One of my main foci on the project was performance and caching is one of the most effective ways to achieve that for a WCM solution. We enabled Output, Object and BLOB caching,  configured exclusions as necessary and were quite pleased with the results, especially since issues with BLOB Caching in 2007 have been resolved in 2010.

A few weeks later I was demonstrating these approaches when it was pointed out that we were getting lots of 304 responses. They occurred with each request for a previously-downloaded BLOB Cached asset (more detail added below). Basically, I overlooked the max-age attribute in the BLOB Cache web.config settings. By default, this attribute isn’t present in the web.config file and I simply missed it. Adding this attribute eliminated the 304 results and the caching configuration was complete. Or so we thought.

Edit to provide more detail on the 304 status and Max-Age
A 304 response is a File Not Modified status (not an error), in this case indicating that the browser is making (potentially) surplus checks for each previously-downloaded BLOB Cached file. The max-age attribute gives the file a lifetime in the client’s browser cache in order to reduce these update checks. To be clear, the BLOB Cache stores large objects on web servers to reduce database traffic, but those objects can be served with a max-age attribute that will determine the object’s lifetime in the client’s browser cache. A max-age value of “14400” means that browsers will cache the file for four hours before checking for an update. This means that updates to BLOB Cached content may become stale if this value is set too high. A common value would be “86400” (24 hours) but we were satisfied with the balance at four hours. In our case, making this update has not yielded a perceptible increase in performance with the current levels of traffic, but it’s the sort of thing you want to set appropriately in order to optimise things and to allow the environment to scale.

Continue reading “BLOB Cache, HTTP 304 Results and F5/Refresh”

Office Web App default cache size is 100 GB

Earlier today I noticed some fairly innocuous commentary in the Features that influence the size of content databases section of the Storage and SQL Server capacity planning and configuration (SharePoint Server 2010) TechNet guidance:

“If Office Web Apps are being used, the Office Web Apps cache can significantly affect the size of a content database. By default, the Office Web Apps cache is configured to be 100 GB. For more information about the size of the Office Web Apps cache, see Manage the Office Web Apps cache.”

100 GB? Surely that can’t be right. So I followed the link and found that:

The Microsoft Word Web App and Microsoft PowerPoint Web App generate a series of images to create a rendition of a document that is viewable in the browser. If Microsoft Silverlight 3 is installed, XAML is used to create the rendition. Creating the rendition can consume large amounts of computer resources. To reduce resource consumption, the Word Web App and PowerPoint Web App store the renditions in a cache, created as part of a SharePoint content database. Renditions in the cache are then used for future requests of a view of the same document. In an environment where most documents change infrequently, but are viewed regularly, maximizing the space dedicated to the cache or the expiration period, can improve performance and reduce resource consumption. In an environment where most documents frequently change, you can optimize performance by reducing the space that is dedicated to the cache, or by reducing the time documents are stored in the cache.

So… make sure to plan SQL database disk space accordingly (nb: this is an update to the original post – I originally thought this was front-end disk space). Also note that you can pin the cache to a specific site collection’s content database. Either reduce the cache size (instructions in that link above) and adjust according to performance needs or invest in SQL storage accordingly.

And don’t forget to plunder the enormous investments Microsoft are making in SharePoint 2010 documentation. It’s the only way you’ll find out about all of these considerations.