SharePoint Team Services Performance Tuning
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Welcome to the SharePoint Team Services Performance Tuning Whitepaper. The goal of the whitepaper is three-fold. First it describes the work done to make SharePoint Team Services from Microsoft and the Microsoft FrontPage 2002 Server Extensions a product that provides great performance and scalability. Second, it provides the reader with some useful performance metrics for SharePoint Team Services and FrontPage 2002 Server Extensions. Third, it outlines the tunable settings exposed in SharePoint Team Services.
The paper is broken into three sections:
Section 1: SharePoint Team Services Performance Features will provide the reader with an understanding of the SharePoint Team Services/FrontPage 2002 Server Extensions thread pool, the SharePoint Team Services database cache, the interactions between Internet Information Server (IIS) , Microsoft SQL Server and SharePoint Team Services/FrontPage 2002 Server Extensions, etc.
Section 2: SharePoint Team Services Performance Metrics will provide some of the data generated in our test labs, the methods used to gather these data as well as answer some frequently asked questions. This discussion will help administrators understand how SharePoint Team Services/FrontPage 2002 Server Extensions scales and how best to implement it in their environment to maximize performance.
Section 3: Tuning SharePoint Team Services is a discussion of the different means by which one can tune SharePoint Team Services/FrontPage Server Extensions to improve its performance. This section covers the thread pool settings, database cache configuration, and provides references to tuning resources for IIS and SQL.
The intended audience for this paper is anyone who wants to gain an understanding of SharePoint Team Services and FrontPage 2002 Server Extensions from a performance tuning perspective. You will need a basic understanding of SharePoint Team Services/FrontPage 2002 Server Extensions as well as familiarity with the concepts of caches, multi-threaded applications and server applications. This article is intended as a reference for SharePoint Team Services (which is only supported on Windows 2000 and above) and the versions of FrontPage 2002 Server Extensions for Microsoft Windows. There will be no discussion of the FrontPage 2002 Server Extensions for UNIX.
For the remainder of the paper the term SharePoint Team Services will refer to both SharePoint Team Services and FrontPage 2002 Server Extensions unless otherwise indicated.
On This Page
Section 1: SharePoint Team Services Performance Features
The performance and scalability of SharePoint Team Services represent a significant increase from previous versions of the FrontPage Server Extensions. SharePoint Team Services implements a number of architectural changes to ensure that the product can perform well out of the box and can scale to a specific customer's performance needs by careful tuning of SharePoint Team Services, IIS and Microsoft SQL Server's settings as well as application of additional hardware.
One example of this architectural work is SharePoint Team Services's dedicated thread pool. FrontPage Server Extensions 2000 runs as an in-process ISAPI application that uses IIS's I/O thread pool to perform the work for each request. Because of this, FrontPage Server Extensions 2000 will often tie up the incoming thread while it processes the request, thus keeping IIS from using the thread to handle a new request.
During this process, the thread is effectively removed from IIS's available request queue. Because IIS's default thread pool settings allows a maximum of 256 threads to be spawned in response to user requests, FrontPage Server Extensions 2000 is effectively limited to only supporting 256 concurrent requests. While it is possible to tune IIS to allow more requests, the same basic problem remained. FrontPage Server Extensions is totally dependant on IIS's thread pool and affects IIS's ability to handle incoming requests.
While SharePoint Team Services still runs in-process with IIS it now maintains its own thread pool. This allows SharePoint Team Services to still initially receive requests via IIS but also provides the ability to queue the requests and handle them on dedicated threads, allowing the IIS thread to return to its pool to handle another incoming request. Further, the SharePoint Team Services thread pool is tunable in that the administrator can control the maximum and minimum threads that are allowed in the pool, the request queue size that stores requests if threads are not available to handle them, etc.
The caching features available in FrontPage Server Extensions 2000 have been enhanced for both SharePoint Team Services and FrontPage 2002 Server Extensions. FrontPage Server Extensions 2000 maintains a series of caches for a document's meta-info (information about a document, such as file size, author, etc.) This allows FrontPage Server Extensions 2000 to have fast access to this information by accessing it from the cache vs. gathering the information from the file system. These sets of caches are still available in FSPE 2002 and a new set of caches specific to SharePoint Team Services' database access have been added. These caches help to minimize the amount and complexity of queries sent to Microsoft SQL Server by SharePoint Team Services.
One final note on performance enhancements for SharePoint Team Services/FrontPage 2002 Server Extensions is the fact that SharePoint Team Services now uses a new memory allocation model that reserves memory from a per-thread heap. Performing the allocation on a per-thread basis vs. from the global process heap helps to minimize memory leaks. When the thread completes its task and is no longer needed, it frees its memory and exits. In addition to preventing memory leaks that will eventually cause a server restart, the new memory model dramatically reduces the contention for memory resources since memory allocations are on a per thread basis and not contending for access to a single global memory heap. The custom memory manager is also cache-aware and is performance tuned to SharePoint Team Services the application.
Section 2: Current SharePoint Team Services Performance Metrics
SharePoint Team Services scalability and performance testing was performed throughout the development process. The testing team worked closely with the development team to verify that the performance features were working correctly and to diagnose and fix any scalability problems that were encountered.
Scalability data was gathered using the Web Capacity Analysis Toolkit (WCAT) to generate multi-user transactions that fell into four different categories or mixes. These mixes covered a subset of the SharePoint Team Services feature set and are described below:
SharePoint Team Services Browse Load Transaction Mix – This set of operations consisted of all browse operations to a Web site based on SharePoint Team Services. For example, browsing to the home page, browsing to the announcements list, browsing to a new list, etc.
SharePoint Team Services Data Editing Transaction Mix– This set of operations consisted of data updates of a Web site based on SharePoint Team Services. For example, creating new lists, adding data to an existing list, deleting a list, etc.
Office Client Transaction Mix – this set of operations consisted of operations that are generated by the Microsoft FrontPage client as well as the other Microsoft Office applications (Word, Excel and PowerPoint.) For example, opening a Web site, saving a document to an SharePoint Team Services Document Library, etc.
Admin Transaction Mix – This set of operations consisted of admin types of operations. For example, creating a new Web site, adding a new user, etc.
The testing lab consisted of a series of client machines used to generate the load and a set of front-end and back-end servers used to run SharePoint Team Services and Microsoft SQL Server 2000. The client machines were six identical Compaq DeskPro computers (Celeron Processors, 128MB RAM) running Win2K professional. The front-end servers consisted of 2 Compaq DL380 servers running Windows 2000 Server. Both servers had 2 500 MHz PIII processors with L2 cache sizes of 512KB. Each server had 1024 MB of RAM as well as RAID storage. The back-end servers consisted of two Compaq DL380 servers running Windows 2000 Server. Each back-end server had dual 800MHz PIII processors with L2 cache sizes of 512K, 768MB of RAM and RAID storage. The network used for the tests was a switched 100Mbs Ethernet. All machines were hooked directly to the switch.
Each of the transaction mixes listed above was run at varying user levels (WCAT Users) against one front-end server remotely connecting to a SQL Server 2000 database on one backend server. For more details on running SQL locally and/or how many front-end IIS/SharePoint Team Services servers are needed for one backend SQL server, please see the section titled Database Metrics . Each of the mixes was run against a single host-based virtual server configured with SharePoint Team Services. The site contained a significant amount of user data: 15 lists, 4 document libraries, 2 discussion forums, with 100 items in each of the lists, document libraries and discussion forums. For brevity, only the SharePoint Team Services Browsing results and the Office Client Operations have been included in this document.
SharePoint Team Services Browsing Transaction Mix
Operations that display the data contained in a site are some of the most important operations for the SharePoint Team Services product. SharePoint Team Services sites are used most often to retrieve team-wide information by individual team members. Given this fact, the development team spent much of its time optimizing for the browse scenario. Using the hardware and testing harness described in the first paragraph of this section, the development team was able to reach a maximum throughput of about 75 browse requests per second for the home page of the test site. This maximum was achieved using about 50 simulates users. Increasing the number of users causes the responses/second to fall, but very gradually, still running at around 60 responses per second at the 1000 user mark.
See Figure 2.0: Responses/Second - SharePoint Team Services Browse Load for the resulting data.
Response time for browse operations increases linearly as the number of users increase, ranging from an average of 146 ms at 50 concurrent users up to an average of 14145 ms at 1000 concurrent users. See Figure 2.1: Response Time - SharePoint Team Services Browse Load for more the results.
Office Client Transaction Mix
Another key scenario for the development team was to optimize access to SharePoint Team Services sites by the different applications that make up the Microsoft Office package. The Office Client Transaction Mix simulated the activity applications such as Microsoft FrontPage and Microsoft Word editing a Web site based on SharePoint Team Services. These operations included everything from opening the Web site to retrieving a document to listing the contents of directories. The mix represented a subset of the client operations taking place most often on typical FrontPage Server Extensions/SharePoint Team Services sites. Figure 2.2: Response/Second Office Client Transaction Mix shows that the maximum throughput achieved using the system described earlier was around 59 responses per second which was obtained using 40 concurrent users. As was evident from the results of the SharePoint Team Services Browsing Transaction Mix, as the number of concurrent users rises, the throughput slowly starts to decline, but is still a respectable 50 responses per second at the 1000 concurrent user mark.
Figure 2.3: Response Time - Office Client Transaction Mix shows that the response time increases linearly as the user load increases. The average response time ranges from 167ms at 40 concurrent users up to 17713 ms at the 1000 concurrent user mark.
Number of Concurrent Users
The number of concurrent users that SharePoint Team Services can support depends entirely on the types of transactions that are being processed. For lightweight transactions like browsing to the home page of a simple Web site based on SharePoint Team Services, SharePoint Team Services can support a higher number of concurrent transactions than the same hardware attempting to support the same number of users performing FrontPage authoring or administrative operations. That said, in the majority of the development team's testing SharePoint Team Services hit maximum throughput at or around 40 to 50 concurrent users. As the user level increases the response time slowly increases (and requests per second decreases in response) but not until the thread pool's request queue is totally full and no threads are available to handle a request does the user get a 'server too busy' error. Given the default settings for the thread pool's request queue's size of 1024, the point at which users will experience a "server too busy" error generated by SharePoint Team Services/FrontPage 2002 Server Extensions is well beyond 1000 concurrent users.
To some extent changing the thread pool and database cache configuration settings described later in the paper can extend the number of concurrent users that SharePoint Team Services can support. For example, changing the maximum number of threads that can be created to a higher value will allow more concurrent processing. Of course hardware additions would have to keep up with these changes to ensure that the system has enough resources to keep from spending all of its time handling the increased overhead that the extra threads need to run. Please see Section 3: Tuning SharePoint Team Services for more information.
SharePoint Team Services Database Information
Please note that the sections below dealing with the Microsoft Data Engine (MSDE) and Microsoft SQL Server are only applicable to SharePoint Team Services and its use of a backend database store. The information is not applicable to the FrontPage 2002 Server Extensions.
SharePoint Team Services uses a database as the back end storage repository for lists, document libraries, discussion forums, etc. SharePoint Team Services can use the Microsoft Data Engine, SQL Server 7.0 or SQL Server 2000 as its back-end storage. The following sections will cover many issues dealing with SharePoint Team Services's use of SQL Server/MSDE as its data store, but in general tuning SQL via established methods will always help SharePoint Team Services performance.
Remote vs. Local SQL
SharePoint Team Services can use Microsoft SQL Server either remotely or locally to store its data. Installing Microsoft SQL Server locally with SharePoint Team Services will cause contention between the two for memory, processor, and other machine resources. Installing SQL Server to a separate machine will avoid many of these points of contention and will give the best performance overall, even allowing multiple SharePoint Team Services front-ends to use the same SQL server back-end. All of the performance results for the different transaction mixes were obtained running against an SharePoint Team Services front-end server connecting to a remote Microsoft SQL Server 2000 back-end.
If administrators do choose to install SQL Server locally, there are two settings that should be tuned to improve performance of SharePoint Team Services. First, make sure that OLEDB is set to use Named Pipes to connect to SQL server during transactions (the default is to use TCP/IP sockets which don't perform as well when connecting to a local SQL install) . To set OLEDB to use Named Pipes instead of TCP/IP Sockets use the Client Network Utility included with Microsoft SQL Server. Second, set SQL to use a fixed amount of memory.. A good rule of thumb is to allow SQL Server to have up to one half of your available memory. You can use SQL Server's Enterprise manager to enable this setting. When SQL Server is not set to limit its memory consumption, it will allocate as much memory as possible. This will cause IIS's inetinfo.exe process to start to paging to the disk because of page faults. If you are installing SQL remotely, let SQL Server manage its own memory allocation.
Also, if SQL Server is installed remotely you can expect about a four to one ratio of SharePoint Team Services front-ends to SQL Server back-ends to reach the maximum capacity of SQL Server (assuming a reasonably configured SQL Server back-end). This means that one SharePoint Team Services installation will work fine against a SQL Server back-end but it will take as many as four equivalent SharePoint Team Services installations running against the same SQL Server back-end to reach maximum capacity.
MSDE vs. SQL Server
During setup SharePoint Team Services will install and configure MSDE 7.0 by default if no version of Microsoft SQL Server is available. As mentioned in the last section, installing SQL Server remotely will provide the best performance for an SharePoint Team Services installation. MSDE 7.0 is a limited version of SQL Server in that the database is limited to 2 gigabytes and MSDE is throttled for about five concurrent users (note that this is users, not connections) As you will see in the next section, MSDE is fine for small workgroups but for best performance for larger workgroups or corporate installations Microsoft SQL Server should be used.
Provisioning SharePoint Team Services for multiple virtual servers will create one database for each virtual server onto which SharePoint Team Services is installed. The database created during the default provisioning process takes up about 2.8 MB of disk space. This total is made up of 2.2 MB for the data file and about 500KB for the log file. The database cannot be shrunk after it is created but after adding data to the site the database can be shrunk to decrease the amount of disk space used. Performing the shrink operation in SQL Server's Enterprise Manager periodically will keep the databases sizes to a minimum.
Adding empty individual lists to the site adds between 100KB for a default Custom list to 150KB for a default Contacts list (the other default lists fall in between these ranges) Of course, this doesn't take into account the data that is added for those particular lists nor does it take into account the files added to the front-end server's file system.
Creating a new Web site underneath a root SharePoint Team Services installation adds about 1024 KB of data to the database's data file. Again, the 1024KB doesn't take into account any data added to the Web site's Lists nor does it factor in any files added to the front-end Web server.
Microsoft SQL Server 7.0 and 2000 don't have a set maximum data file size for an individual database. This allows SharePoint Team Services databases to grow to as large a size as the server's disk system can support. However, as databases grow in size the performance characteristics of SQL Server (and consequently SharePoint Team Services) can change. See the conclusion section of the whitepaper for links to more information on optimal tuning settings and sizes for Microsoft SQL Server.
Since MSDE 7.0 is set to only allow a maximum data file size of 2GB, the theoretical maximum number size of a virtual server of an SharePoint Team Services implementation is also 2GB. This means that the maximum number of Web sites that an SharePoint Team Services virtual servers can support when using MSDE as its back-end data store is about 2045. Again this is a theoretical maximum since these Web sites are empty sites with no data. This also doesn't take into account the disk space needed on the SharePoint Team Services front-end.
Please note that the limits given for virtual servers and Web sites are only for MSDE 7.0 and also only apply to SharePoint Team Services. Since the FrontPage 2002 Server Extensions don't make use of a back-end data store, the maximum number of Web sites is based solely on the performance aspects of FrontPage 2002 Server Extensions and Internet Information Services (IIS).
Virtual Server and Web Limitations
Web sites based on SharePoint Team Services can be installed to top-level virtual servers, as Web sites under an existing virtual server or a combination of both. Virtual servers are top-level entities in IIS while Web sites based on SharePoint Team Services are virtual directories residing under a virtual server. The maximum number of virtual servers and Web sites that SharePoint Team Services can support on one machine is limited by a number of factors, some of which are controllable via hardware upgrades and performance tuning and others that are simply due to architectural aspects of IIS, SharePoint Team Services and Microsoft SQL Server.
IIS uses a data structure called the metabase to store configuration information for virtual servers, virtual directories, etc. SharePoint Team Services make use of the metabase to get and set information about its configuration. Unfortunately the metabase has performance limitations on how many entries it can contain. As the number of entries in the metabase grows, access to specific entries begins to slow. Since each Web sites based on SharePoint Team Services and/or virtual server adds at a minimum six virtual directories, scaling out the number of Web sites or virtual server will affect the scalability of IIS's metabase and therefore the scalability of SharePoint Team Services/FrontPage 2002 Server Extensions operations that rely on the metabase.
One other aspect to consider is the type and frequency of locking that is performance by SharePoint Team Services/FrontPage 2002 Server Extensions on both the Web site and virtual server levels. SharePoint Team Services serializes access to contentious resources during document updates and virtual server wide configuration changes. For example, suppose that two Web sites, /subweb1 and /subweb2, exist under a single virtual server. If a theme operation is begun against /subweb1 a web-level lock is applied and all document updates directed at /subweb1 will be serialized until the theme operation is completed. However, access to the other Web site, /subweb2 will not be affected by the operations on /subweb1. During virtual server wide configuration changes, a more coarse grained lock is applied that will serialize all configuration changes. For example, if a request is sent to create a new Web site, /subweb3, while attempting to delete /subweb1, the creation request will block until the delete of /subweb1 is completed.
Most SharePoint Team Services features perform better when the sites they operate on are spread over virtual servers instead of Web sites. See Figure 2.4: SharePoint Team Services Browse Load - Virtual Server vs. Webs Comparison for a comparison of the equivalent set of browse load operations hitting SharePoint Team Services installed to 1000 virtual servers and 1000 Web sites.
Section 3: Tuning SharePoint Team Services
SharePoint Team Services ships with factory default settings for many of its different caches, pools, etc. These defaults were chosen to give the best performance possible on the machines available in our testing lab but they may need to be tuned to get the best performance out of an individual installation. Determining how to tune these settings and to what extent performance is increased (or decreased) based on the change isn't an exact science. Given that the load on a Web site based on SharePoint Team Services can vary from day to day and even from hour to hour, the best approach is to determine where your bottleneck lays using established methods and make slight adjustments while observing the results. Please refer the end of this section for resources on performance monitoring, testing and tuning.
The development team for SharePoint Team Services did most of its performance testing using off-the-shelf dual processor boxes with 1GB of RAM. To achieve similar results to those given in Section 2 administrators should obtain similar hardware. However, if a bottle neck appears during the lifetime of an SharePoint Team Services installation, adding hardware can often help to improve the performance and scalability of SharePoint Team Services. For example, adding additional processors to a machine running SharePoint Team Services will increase the throughput for most operations. See Figure 2.5: SharePoint Team Services Browse Load - Processor Scalability for a comparison of the same operation mix run against a Quad Proc Dell PowerEdge 6300 with one, two and four processors enabled. You can see that increasing the number of processors on a machine hosting SharePoint Team Services will increase throughput. Note that for this test no tuning took place of the SharePoint Team Services thread pool, SharePoint Team Services Database cache or the FrontPage 2002 Server Extensions document caches. Carefully tuning these settings as per the discussion in the next section could increase performance even more.
SharePoint Team Services Performance Tuning Configuration Settings
The SharePoint Team Services thread pool and database caches are configurable by setting a number of registry keys that reside at the following section in the registry of the front-end SharePoint Team Services server:
HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Shared Tools\Web Server Extensions\All Ports.
Once a change has been made, IIS must be restarted to pick up the change. All of the keys described below should be set as DWORDs in the registry. If they are set to strings the setting will be ignored. The keys and their associated values are described in the following sections titled: Thread Pool Configuration Settings, Database Cache Configuration Settings and FrontPage 2002 Server Extensions Document Caches.
Important Note Any changes to the registry may disable your SharePoint Team Services installation or even worse your Windows 2000 installation. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.
Thread Pool Configuration Settings
Administrators can configure the SharePoint Team Services thread pool by setting any of four registry keys that control the minimum and maximum numbers of threads that will reside in the thread pool, the size of the request queue that will queue requests that cannot be handled immediately and the timeout value used to trim the thread pool of idle threads. Keeping the thread pool tuned helps to increase throughput for an SharePoint Team Services installation. Please note that changes to the SharePoint Team Services thread pool will affect both SharePoint Team Services operations and FrontPage 2002 Server Extensions operations. Also note that all changes to the SharePoint Team Services thread pool configuration settings are machine-wide operations that will affect all SharePoint Team Services sites on the box.
This setting controls the minimum running threads that will stay resident in the thread pool once they have been created in response to an incoming request. The default value of this setting (if not set in the registry) is 2 * the number of processors on the system. To enhance response time when the system is under load, you can increase this value. However, the better response time comes at the expense of memory. The setting is per-processor, so the actual minimum number of threads will be equal to minthreadscount multiplied by the number of processors on the system. By increasing the number of minimum threads that stay resident in the pool you avoid the added cost of creating these threads in response to a request. minthreadscount will always be at least 1 * number of processors, even if set to zero by an Administrator.
The maxthreadscount setting controls the maximum number of threads per processor that will be created in the thread pool to service incoming requests. Once this threshold is reached, all further requests will be placed into the thread pool's request queue for processing once a busy thread has completed its task. The default value (if not set in the registry) is 32*the number of processors on the system. The setting is per-processor, so the actual maximum number of threads will be equal to maxthreadscount multiplied by the number of processors on the system Increasing this value will increase the use of system resources (both memory and processor usage) but will also increase concurrency by allowing the system to spawn more threads in response to incoming requests. Be careful of setting maxthreadscount to too high of a value. If you increase the number of threads beyond a certain threshold (determined by processor speed, request type and available memory) your system will spend all its time managing the overhead of context-switching between all of the running threads. This will actually decrease performance of the entire system.
Remember that the total number of threads that SharePoint Team Services will create in response to this setting is per processor. If you want 256 threads and you have 2 processors, set maxthreadscount to 128. The maxthreadscount cannot be set to lower than minthreadscount * number of processors.
The requestqueuesize setting controls the size of the SharePoint Team Services thread pool's request queue. The request queue is used to hold requests that cannot be handled immediately due to the fact that all of the threads in the thread pool are busy and the system has already reached maxthreadscount active threads in the pool. The setting defaults to 1024 which means that up to 1024 requests can be queued up when SharePoint Team Services cannot allocate a thread to handle an incoming request. Once SharePoint Team Services has created maxthreadscount threads and the request queue is full, new incoming requests will receive the "Server Too Busy" error. If users are seeing this error consistently when the system is under load, one option is to increase the size of the request queue. requestqueuesize will always be at least 1, regardless of the registry setting. Note that setting requestqueuesize to too high of a value can have the negative consequences of both higher memory overhead to manage the request queue's data structures and increased server latency due to SharePoint Team Services processing the queued requests before accepting new requests.
The threadtimeout setting controls the timeout value that will terminate idle threads in the pool. If no requests are being processed, all threads that were created previously are terminated until only minthreadscount * the number of processors on the system threads are running. This helps to save system resources by not incurring the overhead of managing the idle threads. The setting defaults to 30000 ms. The larger the value of the threadtimeout setting the longer it will take SharePoint Team Services to reclaim resources it has expended during bursts of activity. Try tuning threadtimeout to a lower value to reclaim the resources more quickly. The threadtimeout value cannot be set to less than 100ms.
Database Cache Configuration Settings
The database cache settings are per machine and control the minimum sizes of three caches that are maintained in memory to help improve response time for SharePoint Team Services features. Please note that these settings have no affect on FrontPage 2002 Server Extensions features. These caches will cache meta-information for lists and document libraries, projects (Web sites) and SharePoint Team Services users for all of the SharePoint Team Services sites on the machine.
As lists/document libraries, projects and users are added, used and deleted, the meta-info that is generated is stored in the appropriate cache. This meta-info has many different uses, including being used to generate the appropriate queries to get list and document library data, get project settings for each Web site based on SharePoint Team Services, etc. The goal of these caches is to keep the number of queries sent to SQL Server to a minimum as well as to minimize file system access.
As long as operations are taking place and unique entries are being added to the caches, they will grow without bound. However, to help minimize memory problems due to stale entries left in the cache and to avoid overusing memory, SharePoint Team Services provides a cache trimming thread that awakens at a pre-determined interval and trims the caches down to their minimum sizes.
Think of the database cache settings as the minimum maximum size acceptable for each cache. An example will help to clarify this process. Suppose that one Web site based on SharePoint Team Services on a machine has 1500 lists on it that have all been requested in less than five minutes. Currently the cache that SharePoint Team Services maintains for lists meta-info has 1500 entries in it. After 5 minutes has passed, the SharePoint Team Services database cache trimming thread wakes up and trims this cache back down to 1000, the default value for the lists cache size. The trimming algorithm gets rid of the least recently used entries first to try and maintain temporal locality for any operations that are still continuing.
The dbcachelistsmax setting controls the maximum size of the Lists cache after trimming out the least recently used items. On machines that don't have many lists, you can save memory overhead if you lower the value for dbcachelistsmax. Note that this will affect response time by increasing cache misses which force SharePoint Team Services to do more work to get the data. On systems with larger amounts of memory, increasing this value will help response times by allowing more items to remain in the cache. However, this increased response time will come at the expense of the extra memory used to maintain the cache.
The default value of dbcachelistsmax is 1000 if not set in the registry and cannot be set to a value lower than 1.
The dbcacheprojectsmax setting controls the maximum size of the projects cache after trimming out the least recently used items. Note that in SharePoint Team Services the terms project and web are equivalent. Just as with the dbcachelistsmax setting, you can save memory on machines with fewer Webs than the default value of dbcacheprojectsmax (across the entire box) by setting dbcacheprojectsmax to a lower value. Conversely, if the machine contains more than the default value of Web sites you can increase this setting to get better response times from operations that use the Web site's meta info. The dbcacheprojectsmax setting defaults to 200 Web sites if not set in the registry and cannot be set to a value lower than 1.
The dbcacheuserinfomax setting controls the maximum size of the UserInfo cache after trimming out the least recently used items. Just as with dbcachelistsmax, you can save memory on machines with fewer users than the default value of dbcacheuserinfomax by setting dbcacheuserinfomax to a lower value. Conversely, if you have extra memory and more than the default value of users on your machine you can increase this setting to get better response times from operations that access the UserInfo table. The dbcacheuserinfomax defaults to 2000 users (for the entire box) if not set in the registry and cannot be set lower than 1. Note that for each Web an SharePoint Team Services user is a member of, the UserInfo table will contain a separate entry. For example, if User1 is a member of /subweb1 and /subweb2 then the UserInfo table will contain two separate entries.
The dbcacheaginginseconds setting controls the time interval that determines how often the database cache trimming thread wakes up and trims the three database caches. Decreasing this value will decrease memory usage because the caches will be trimmed down more often but will increase processor utilization while performing the trim. Increasing this value will let more entries accumulate in the three database caches which will result in increased response time (assuming those entries are needed) but will result in less memory available because the caches are not being trimmed as often. The default value of dbcacheaginginseconds the setting is 300, so every 5 minutes the database caches are trimmed back down to their maximum sizes. The dbcacheaginginseconds value cannot be set to lower than 1 second.
FrontPage 2002 Server Extensions Document Caches
The FrontPage 2002 Server Extensions maintain a separate set of caches that aid read and write operations that make use of document meta-information. These caches and their associated configuration variables work the same way for FrontPage 2002 Server Extensions as for FrontPage Server Extensions 2000. For more information on how these settings are used, see the Command-line Properties section of the SharePoint Team Services Administrator's Guide at http://www.microsoft.com/technet/prodtechnol/sppt/sharepnt/proddocs/admindoc/ows000.mspx
Answering any question with respect to performance of a software product always ends up depending on the situation. What hardware is available, what are the characteristics of the user load for peak and normal operations, what other software is contending for resources are all variables that affect the performance of an individual product. One thing to keep in mind when tuning your specific implementation is that SharePoint Team Services makes use of a system of interdependent software packages, all of which can and should be tuned before, after and during any attempt to tune SharePoint Team Services. SharePoint Team Services runs on Windows 2000 Server, is hosted within Internet Information Services (IIS) and uses Microsoft SQL Server as its back-end data store. Each of these elements has its own configuration settings that should be configured to achieve the best performance possible. After changes are made tests should be conducted to verify that the change actually increased performance. Use the following pointers as resources for tuning and testing your SharePoint Team Services installation.
For information on tuning Windows 2000 Server, see http://www.microsoft.com/WINDOWS2000/server/evaluation/performance/reports/perftune.asp
For information on tuning Microsoft SQL Server 2000, see http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/default.mspx
For more information on WCAT and how you can use it to test your SharePoint Team Services installation, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dniis/html/usingwcat.asp.