There are always some chuckles and smiles when I tell an audience that SharePoint is a great application but lends itself well to optimization, a preaching to the choir vibe if you will…
The way I see it there are 2 main areas in which the most performance can be gained, by optimizing the front-end, the content itself before it is delivered to the client device, and by optimizing the storage back-end.
Optimizing the front-end is what Riverbed is focused on with WCO (web content optimization), the main idea of which is to minimize the number of round-trips required between front-end server and client device. The way WCO does this is to merge the majority of the objects that make up the web page, less objects equals less round trips. Less round trips over a latency inducing (i.e. WAN) network equals a far faster browsing experience. (how cool would it be if you no longer need to wait on the application but instead you make the application wait on you!).
We do this by placing a virtual appliance (called the Riverbed Stingray Traffic Manager) which runs the WCO functionality called Stingray Aptimizer in front of your SharePoint servers (you can also get this module separately if you want to install it on your SharePoint front-end webservers without the Stingray Traffic Manager).
The immediate impact the user sees is that the load time of the SharePoint portal is much (up to 4x) faster.
So now that we have optimized the front-end experience the second thing we can look at is the back-end. SharePoint uses MS SQL server to store not only the metadata (discriptions) of the files but also the binary (office documents, pictures, videos,…) objects. As SQL server is not generally optimized to handle binary large objects (BLOB) efficiently there is a real risk of slowing down your application once you have a certain amount of data you need to work with.
Typically, as much as 80 percent of data for an enterprise-scale deployment of Microsoft SharePoint consists of file-based content that are stored as BLOB data. These BLOB objects comprise data associated with Microsoft SharePoint files. However, maintaining large quantities of BLOB data in a Microsoft SQL Server database is a suboptimal use of SQL Server resources.
What you can do is separate this out so the SQL server does what is does best (store and retrieve the metadata) and a separate storage environment is used to store the objects itself.
One such solution is to put the SQL server on a block storage device (like the dell equallogic for example) and put the binary data on a content addressable storage device (like the dell DX6000), you then need a middle man (like the stealth content store software) to decide where to store what part.
A schematic overview of this solution is depicted below.
The idea is that the data is written and retrieved much faster if you have each part of the solution focused on it’s own strength.
So now we have optimization on the front-end by using WCO, optimization on the back-end by splitting out BLOB storage from metadata storage, assuming now that you SharePoint deployment is centralized and you have clients using it in branch locations you can still accelerate the experience.
If the client in the branch needs to check-out a file then this file still needs to travel over the WAN, we can greatly accelerate this transfer by using our Steelhead WAN optimization solutions.
Disclaimer: I used to work for Dell so my default thinking goes to their products but you can build this using the vendor of your choice of course.