The Top 10 Problems With SharePoint Performance Top 10 Lists

I’ve come across lot’s of helpful lists around the net and forums on the topic of performance tuning SharePoint however as time and performance projects march forward it’s clear that this subject, more than most in the already dense realm of SharePoint, deserves a more realistic outlook. The standard lists of performance tuning tips look at the forest for the trees. This list looks at the forest as a melee battle between good and evil and er.. anyhow, read on for some twists on the old tuning bag of tricks:

1. Wack a Mole Syndrome

Get verified, fully detailed user stories complete with IP address, browser version/settings/plugins, OS version, Fiddler, YSlow debug reports, etc. BEFORE making any analysis. Failure to do so (resulting on heresay, opinions or assumption) will lead to a non-productive game of wack-a-mole.

2. SharePoint performance tuning is incremental, not subtractive

1 + 1 does not equal 2 when untying complex relationships between SharePoint, IIS, Active Directory, SQL, Project Server or whatever else is in the mix in your SharePoint performance issue. For example, in one farm we found reducing the SharePoint object cache file size from 500 MB to 100 MB caused a corresponding reduction in the W3WP.exe process for that web application from 1.5GB to 300MB – sometimes resource problems are exacerbated in a bell curve (or even less predictable patterns) rather than an simple formula.

This requires multiple passes at problem resolutions, resolving one (or one group of) problems at a time rather then just running through a laundry list of to-do items and calling it a day. You have to be able to get buy-in from your client or team that the issue(s) may not be nailed with one go at it.

3. Scale up or scale out

We all know SharePoint plugs in as a web farm out of the box. You have your App Servers, your Web Front Ends, your Search Servers etc. What is more of a grey area is the threshold of, when does one add more RAM/better CPUS/Disks, versus adding a secondary App or WFE server? There are tools like the HP SharePoint Sizer which try and point you to the hardware required based on some fixed (in that case, vendor-specific) formulas. The only way to get an accurate assessment of when it’s time to order some new servers or whether you just need your VM guys to allocate some more RAM, is to have an SharePoint Consultant complete a full assessment of your situation.

Following a cookie cutter table of specs and platforms will just lead to grief.

4.Cumulative Updates, Service Packs, Regressions demand constant attention

You need to be in the mix with SharePoint day-in, day-out in order to keep on top of the various updates, regressions, bugs and workarounds. What may solve Performance Problem X may work on CU but not another. Committing to performance fixes without knowing how they sit in the living, moving behemoth of code that is the SharePoint framework is the path to frustration.

5. VMware abstracts the problem


Virtualization is popular. Virtualization allows IT guys to give the guys in suits what they need with the push of a button rather than with capital PO’s. Therefore: VM admins have an increasing importance in organizations as they are power brokers who can called on to quickly breath life into stakeholders projects by giving them the virtual juice they need. The problem seems to be that the new-found speed of infrastructure deployment has downplayed the old tendency of hyper-critical evaluation of infrastructure – when we used to pay for every nut and bolt of a new server farm deployment the specs involved would be of supreme importance and it seemed more thought was given as to what the applications deployed on the hardware actually require.

Particularily due to SharePoints tendency to be adopted as a fragile pilot project (and subsequently taking the company by storm and absorbing silos left right and center), there is a trait of starting off farms on VM’s starved for resources with the idea “well if this isn’t enough then we can just flip the switch and add more (RAM/Disk/CPU) later”. This is a recipe for a rocky SharePoint adolescence – there are many aspects of virtualization that do not add

For example, Disk Defragmentation of the guest OS is considered a laughable or even harmful tactic by many VM admins. I try to disprove that (with Bob Nolan of PerfectDisk’s generous help) in my blog post here.

Brent Ozar is a kingpin on the topic of SQL virtualization and he point’s out some reasons on why you should perhaps not virtualize SQL server at all.

So try explaining that stuff to your local Xerxes VMWare Admin

6. Company Politics


Company politics makes keeping a sensible amount of web parts and content on the page difficult. Design by Committee results in the inevitable ultra-busy intranet home page which will invariably contain:
– A Yahoo stock ticker
– A photo slideshow
– Pictures of the CEO and Board of Directors
– Some form of social company initiative e.g. employee of the week and their hobbies
– ..and so forth

Each one of these little pieces of real estate on the homepage has typically been fought for by stakeholders in meeting after meeting. Frustration levels rise as initiatives may get squashed from higher up. People get asked to come in on Saturday to fix up a webpart, emotional investment in particular web parts or content grows.

Now you, as the one assessing performance, come in and see that this assembly of intentions is actually overloading the Win XP / Internet Explorer IE7 workstations of the end users or there are too many SQL connections coming from some custom web part. Your recommendation of stripping off web parts and content falls in line with modern usability best practices. Be ready for the sparks to fly, or even worse, for nothing to happen at all as this emotional investment in content or functionality may preclude the client from giving you the ability to actually resolve the problem.

You can tell the trurth and share that time and time again you have seen a simple search interface on the home page, combined with with key navigation elements, result in the best user experience. Be prepared to be told to fix up performance some other way as the politics factor may preclude you from being able to get the job done.

7. Best practice or immediate fix? Guess which one impresses SharePoint stakeholders more.


Related to the 6. Company Politics section, opinions rarely sail on the same seas as performance tuning. Custom branding or development decisions may lead to Catch 22’s which prevent you from making the “right” choice. “This ain’t drywalling” is a nice saying of mine, but really, sometimes we are required to just slap some stuff on top of a problem area.

8. It’s the Content, Stupid

90% of web page “load” is typically getting content from the server to the client browser and the time it takes for the browser to render it.The following items are exacerbating the situation with SharePoint:
– Jquery-enabled web parts
– Content Editing staff who sneak in random Javascript/Jquery into Content Editor Web parts in order to achieve a quick fix to a layout or design issue, instead of creating custom branding or web parts. This Javascript is fired off at all kinds of random moments in the page life cycle if not carefully controlled and causes hiccup effects in the page load
– The ease of which people can upload images into SharePoint means more than ever we are seeing staff who upload non-web optimized images into SharePoint, resulting in the classic scenario of a home page slide show with 7 five megabyte images

So the problem reverts from being a “SharePoint” problem and becomes a plain ol’ web content management problem. This is an important distinction to make during a performance assessment as there are often stakeholders who have spent years perfecting their mastery over their “silos” (Lotus Notes, Oracle etc.) who now have to submit to the crushing (yet invigorating) force of complete corporate assimilation by SharePoint – and they would like very much to pin performance issues on the SharePoint boogeyman. Being able to isolate basic web content management issues is vital and could potentially lead to considerable savings in a performance roundup as web content consultants are generally cheaper then SharePoint consultants.

9. Maytag Repairman Syndrome

You can run through all the TechNet best practices and fix up loose ends that the original SharePoint farm architects may have missed or misunderstood. You can set up quotas, split up content DB’s, and generally soup up that farm for all she’s worth: however unless you carefully document what you’ve done and can provide accurate projections of before and after results no one will ever notice your work. You will end up racking up the hours and become an underappreciated lonely repairman without any work as the tuned up SharePoint farm sails smoothly away into the future.

10. Integration is Exacerbation

SharePoint’s key benefit to an organization is it’s integrated environment. It is a Document Managment system, Corporate Homepage, business process repository (workflows) and more. The good news is that more and more legacy and external systems are being rolled up or tied in to the SharePoint framework. The bad news is that when you wire up your Oracle, Project Server, or specialized industry-specific software suites into SharePoint you can compound performance problems. This is why using tools such as Red Gate’s Memory and Performance Profiler tools can help you isolate leaky or load-generating .DLL’s and connections.

Performance

Leave a Reply

Your email address will not be published. Required fields are marked *