1

I guess the most common SharePoint-Server constellation is a small farm: one Database-Server and one Web Front End (WFE). The default-configuration of SharePoint (WSS 3.0 / MOSS 2007) does not seem to be the optimal or best practice configuration for this kind of SharePoint-Server farm.

So what could/should I do to get a better performance?

  • should I reconfigure the workflow-settings?
  • is there a database-setting I should change?
  • etc.

Update: I assume the SharePoint-Server is used as a collaboration-server, with "TeamSites" and websites with custom lists, various workflows running on that lists, lots of document-libraries, etc.
One optimization for a SharePoint-Server in that category is IMO to Change the Recovery Mode of the database to prevent large database files.

Dave M
  • 4,494
  • 21
  • 30
  • 30
user10082
  • 195
  • 2
  • 5
  • 8

2 Answers2

3

Not to be too controversial, but I think you're making some very large assumptions with your question. Let's start with farm configuration.

In my experience, I don't think I've seen any one configuration that's more common than another with one notable exception: "development" servers. Devs tend to lump everything into one VM (or one box), simply because it's easiest to prototype. This is done without any real eye towards expected load or farm purpose -- it's a convenience thing.

When it comes to production farm configuration, though, the purpose and expected load on the farm should drive its configuration. This is the whole basis behind tools like Microsoft's System Center Capacity Planner (SCCP) (http://www.microsoft.com/systemcenter/en/us/capacity-planner.aspx - free download). You plug in your expected user load and what the farm will be doing, and you get a baseline recommendation out. It's not a one-size fits all, but it provides a solid starting point for further planning, customization, and tuning.

Though user load tends to be one of the bigger drivers in "number of boxes" to throw in a farm, the intended purpose of the farm is going to drive a number of configuration and tuning aspects. You asked about "better performance" in your question, but you need to answer this question: what is the farm going to be used for?

To use two disparate examples, performance tuning suggestions will vary significantly based on whether a farm will be used for collaboration (the classic "team sites" scenario) or publishing (that is, an Internet-exposed "banner site"). At a high level, optimizations for the former are going to drive towards maximizing R/W performance, while tuning for the latter will focus on maximizing caching performance and minimizing response time.

Though there are some general planning and performance tips that are relevant in most farm scenarios (for example, leveraging 64-bit hardware and software: http://technet.microsoft.com/en-us/library/dd630764.aspx), I would encourage you to start by nailing down two parameters:

  1. Expected user load (both average and peak)
  2. Intended farm purpose (collaboration, publishing, hybrid, etc.)

Once you know those two things, you're in a position to begin estimating your farm size/configuration; you'll also have an idea of where to focus some tuning efforts.

Good luck!

  • No, he is correct when he says the "default" configuration of a SharePoint install is bollocks. You always have to make changes for it to work correctly. – Nat Jul 02 '09 at 21:39
  • I draw a distinction between the phrases "optimal performance" (kpinhack's original post) and "work correctly" (as you said in your comment). I agree with you, Nat, in that there are always some things you need to add, change, or reconfigure for best-practices farm operation. "Optimal performance," though, is a different challenge ... and in my experience, it's really hard to achieve optimal performance without a target. That means identifying the farm's expected user load and the purpose for which a farm is to be used. I don't think we disagree -- just looking at different aspects :-) – Sean P. McDonough Jul 03 '09 at 15:18
1

Sharepoint has many moving parts, and each one can be optimized to increase the overall performance. As a general rule, you should start on the database, and work your way outwards.

I do, however, agree with Sean; you need to more clearly define the workload for the farm as well as its expected future growth.

Jeff Costa
  • 481
  • 3
  • 9