Best ways to Improve Sharepoint 2007 Performance?

Question

OK we are at the end of our rope here, and I’d really appreciate feedback from the SO community.

Our basic issue is slow performance by our MOSS-based intranet--

Some environment info:

We have a MOSS standard edition for a collaboration based site.

• The sitedb is 29 Gb
• we have two VMWare based front end servers. (2x 32bit CPUS each)
• less than 1000 users spread over all timezones
• We have one big site collection with subsites.

General symptoms: Loading front page and pages that have been ‘warmed-up’ is pretty decent- but pages/sites off the beaten path are very slow to load.

We see spikes, where a page all of a sudden takes 30 seconds to load, vs its more normal 2

Here’s what we have done already:

• Scaled way back on crawling
• enabled object and blob caching
• optimized VMware setup
• followed the Microsoft IT whitepaper on MOSS sharepoint best practice (esp list size etc)

I don’t know what else to do here—Split into multiple site collections?

Switch to 64 bit front-end servers?

Would be great to hear from others who have been in similar situations.

Answer 1

You don't say how much memory your front end servers have - given that they are 32bit, I'll assume the maximum per worker process of roughly 2gb + change.

My advice? Switch to 64 bit, add more memory, and check that you are not using just one w3wp worker process per front end. Have a dig into "web gardens," that is to say where you configure multiple w3wp processes per front end. To start with, start with two workerprocesses per front end and see how that works out. Also make sure they are set to recycle, and that the recycling of each pair of worker processes do NOT overlap - having two+ workers means they can take turns to recycle without cutting access.

just my 0.02.

-Oisin

Answer 2

I think your very first task is to determine where the problem actually is - until you know that you are wasting your time changing things.

• Is the database server on a separate server or one of your web servers?

• Do you see a CPU/Disk bottleneck on your front end or db servers?

• It sounds like your world wide; do you see the same performance problems from networks close to the server - is it a WAN issue?

Answer 3

Thanks for some helpful advice all, one thing I just learned was that our object caching has basically not been doing anything! This is because the way it seems to work is that if you have rights to edit ANYWHERE on the site collection, it per default disables object caching across the portal. Since all users have rights to at least something, this means caching was doing basically nothing!

We discovered this by enabling the cache debugging, which puts a small comment in the html about what cache is being used. After changing the setting "Allow writers to view cached content" in the authenticated cache profile,

We are seeing what this does for editors, but for regular viewers, the anecdotal evidence is that it is having a big impact!

Answer 4

Yes, caching is the best way to reduce load on the system. Adding RAM to the SQL server is also good. (64 bit is really a must for your SQL server, WFE not so important).

Not sure if you want to recycle the processes though. I have not evidence for this except a conversation with someone saying the recycling the processes looked to have solved one performance issue, but was introducing others.

Did I mention caching?

The SQL server should handle database up to 100Gb, but at that size they will be hard to manage for backups and the like, so splitting your site into relevant site collections is something you may need to plan for now, but this may not be relevant to performance.

Answer 5

Definitely check the disk usage. If you have two VMs and they run of the same disk / SAN, make sure it isn't too busy. Overloaded SANs kill performance

Answer 6

I'll throw my hat in the ring and recommend 64 bit as well. Perhaps not as an immediate fix, but going forward, I would put a move to 64 bit as a goal for your entire farm.

I'd also take some issue w/ Nat's comment that it doesn't matter on the Web Front Ends. I won't debate benchmarks or argue memory addressability. It's really simpler than that.

Microsoft has publically stated that 2007 is the last version of SharePoint that will run on 32 bit servers. Going forward 64 bit is going to be a requirement - so like the FRAM oil filter guy says - "pay me now or pay me later"...

Answer 7

Hi,

we have also performance problems. We upgraded on win 2008 64bit witch make some difference but not as much as expected.

The bih boost gave us changing from NTLM azthentication to Kerberos. This was our major improvement.

hope this helps to someone

Answer 8

Agreeing with Nat's post (above), caching would be the idle way for resolving the performance issues. Since SQL Server is not optimized to handle binary data efficiently, it is therefore more appropriate to off load BLOBs from database to an external storage like External BLOB Store (EBS) then use caching for speeding up read and write of the sharepoint documents.

Different software are available that let you externalize and cache BLOBs, including Ncachepoint and Storagepoint.

Distributed caching helps not only boost performance but also increase scalability. Ncachepoint uses distributed caching to cache not only BLOBs but also Lists, ViewState and ASP.NET sessions. This is a good piece of software for anyone experiencing Sharepoint performance slow-down and wants Sharepoint to offer best performance even at peak load times.