SharePoint Remote Locations - Don't Lose Your Sausage

Over the last few weeks I have been working closely with a multi-national company to Load Test their new SharePoint 2010 environment. To test that having the SharePoint Server Farm in one physical location can provide a fast and reliable worldwide solution.

Even though I have been testing connectivity from exotic locations such as Sidney, Dubai and Bangkok I have spent all my time during the testing period in the UK. This has meant staying a number of nights at a popular brand of hotels where Lenny Henry probably gets a discount.

One of my favourite parts of hotel stays is always the breakfast. At home I never feel like breakfast before leaving for work but when working away suddenly my morning appetite becomes huge. Now we have the popular buffet style breakfast I seem to eat even more. It is great because within seconds of sitting down you can be eating. A choice of cereals, cooked English breakfast, pancakes, toast, fruit even cakes are on offer. It really is a case of how much you can eat in ten minutes before you have to leave for work. Oh, and avoiding anything that might possibly stain your white shirt.

It is important where your table is in relation to the food and this made me think about where you position your SharePoint Servers. I started to think more about the comparison when on my return to my table after my second visit to the buffet table (well, I was planning to work through lunch) that I tripped on a step and sadly my crispy sausage rolled off my plate and onto the carpet. It continued to roll until it came to rest under a table where another suited business man was seated. Luckily nobody had noticed so I continued my walk to my table leaving my sausage behind. I felt that returning for another sausage would delay my progress so just ate my bacon, scrambled egg (less messy than fried), fried bread and mushroom disappointed that my sausage had not made it. In much the same way during my testing some page requests in SharePoint had not made it in there journey across the Atlantic.

When planning a breakfast buffet you need to think carefully where you position the different parts of the buffet. You need to think first of all about filling the buffet tables. It would be silly to put it miles from the kitchen as it has to be managed and maintained. With the SharePoint servers (Web Front Ends, Application Servers, SQL Servers) these need to ideally be in a location where you have IT staff who can work on them and a location where they can be backed-up. Also with the breakfast buffet it makes sense to put them quite near to the largest amount of diners. The further you have to walk with your hot food the higher the chance of it going cold or you losing your sausage. Also the more people have to walk with the food the more traffic there will be especially at peak times (for breakfast probably 7-30am to 8-15am). The more people moving around the more chance of collisions and dropped packages of cereals. With SharePoint again the servers should whenever possible be located where the highest amount of users are so that requests don't have so far to travel and bottlenecks are not created causing bandwidth issues. Calls to the SQL servers from the Web Front End servers are high with SharePoint so always have these in the same LAN.

It is difficult to know what kind of food a guest will want from the breakfast buffet, but if we did we could possibly position them better. For example, if we had a group of vegetarians you could seat them furthest from the sausages, bacon and black pudding. Maybe put them nearer the muesli. The waiter seating breakfast diners might perhaps look at the size of the guests and then put the slightly fatter ones (like me) nearer the breakfast buffet because they might be more likely to eat more. Also it is better to have skinny people walking around a lot than fatter ones as they take up less room. Again with SharePoint the smaller the size of requests the better. So if you have a large image file you really want to make sure it is cached somewhere and not being retrieved every time. With SharePoint there are different options to cache data. One of these is the Blob Cache which is not turned on by default. When enabled Blob Cache lets you store cached copies of certain file types.

With transporting breakfast items wouldn't it be great if you could make the food items 90% smaller to help you transport them. It sounds like something out of 'Dr Who' but there are hardware solutions available that can do exactly this with SharePoint and other network traffic. Products like Steelhead from Riverbed can dramatically decrease SharePoint traffic with files compressed by a staggering 95%.

Talking of things shrinking by 90% that does seem to have happened to Aston Villa's local rivals Birmingham City hopes this week. From the high of winning their first cup and thinking they are about to become the Kings of Birmingham to a championship side in less than three months. Good luck Blues in your games against the NPower League next season. I am sure you'll get to play the Villa again one day.

In next week's Blog I will talk about Load Testing and how to calculate the number of Requests Per Second your SharePoint system will experience in Peak Hours.


If you require any help Load Testing or Capacity Planning for SharePoint then just ask for an Office Talk consultant by emailing Frank at frank.faulds@office-talk.com.