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! Is this true?
enable cache debugging by changing the setting "Allow writers to view cached content" in the authenticated cache profile. This puts a small comment in the html about what cache is being used.
If servers are 32bit, the maximum per worker process (App Pool) of roughly 2gb + or –.
If the application pools are recycling more and more often then it is time to upgrade to 64 bit
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.
The big boost gave us changing from NTLM authentication to Kerberos. This was our major improvement.
Do this before swithcing to 64 bit to make sure
- Ensure there is no Disk or Bandwidth issues between the DB server and web front ends. The network speed to the database server is critical.
- Check the database server itself, if the disks are on a SAN there may be performance issues if there is contention for the phsyical drive on the san. RAM is also important, the more it can cache to memory the less time waiting for disks to respond.
- Schedule crawling jobs to run outside of regular business hours
- You’ve enabled object caching which can be huge help, be sure to ensure compression is enabled too! For lower bandwidth users sharepoint sends a large amount of CSS information to users that compresses down to 1/10th it’s size if compression is enabled.
- Heres another big one, ensure your companies DNS is working correctly in other locations and look into if this problem is related to external sources. IE we have a sonicwall firewall that is brutal on response times for offices connecting through it for anything.
- Micrsoft has a whitepaper on performance counter monitering. It is very thorough and will help you narrow down the problem between CPU/RAM/Network/HD IO
Q: What is meant by dedicating an app pool to customizations?
A: Essentially when you create your SharePoint web applications you choose which application pool should be used. My recommendation is to consolidate your “vanilla” or out of the box web applications together, and dedicate an application pool that’s heavily customized in its own application pool. Not only will this isolate the customized web application memory space, but also make it much easier to determine if it is the problem if you have memory issues. Essentially it’s giving you memory isolation on your custom apps.
How does performance suffer with alot of web apps on a wfe? Is there a suggested limit?
A: With each additional web application you have additional memory overhead. If they are consolidated in a single app pool this will help, but if not combined each app pool will contain at a mimimum of 200MB of memory and more likely 500MB to 1 or even 2GB per active worker process. Suggested limit is fewer is better. Somewhere under 10 is preferred and even there, consolidate your app pools as much as you can for better performance. There are some hosters getting away with 100 web apps across 4 app pools, but this isn’t recommended for the average customer.
Do not use Web gardens
Web gardens are Internet Information Services (IIS) application pools that are supported by multiple worker processes. We recommend that you do not use Web gardens for enterprise content management sites. This is because Web gardens have negative effects on page output caching.
Carefully monitor use of customizations and Web Parts
Only deploy customizations that follow the best practices described in the following resources:
Turn on only the features you need
Office SharePoint Server 2007 offers many features. Resources will be more efficiently used if you only turn on the features relevant to users. For information about turning off features, see Working with Features (http://go.microsoft.com/fwlink/?LinkID=105337&clcid=0x409).
Do not leave pages checked out
If you are using Enterprise Content Management, do not leave pages checked out. Instead, if it is possible, check them in quickly after every change. Leaving pages checked out reduces the performance of page rendering.