Monitoring and Managing Performance

                 

 
Special Edition Using Microsoft SharePoint Portal Server
By Robert  Ferguson

Table of Contents
Chapter  6.   Capacity Planning Within Your Environment


Once the site is deployed and operational, it is critical to ensure your end users never have to complain about unacceptable performance of the portal site.

To ensure an optimal end user experience, the server must have sufficient resources. This section discusses the server resources that should be carefully managed during a deployment.

CPU

The first resource, and likely the most important, is the CPU. The most CPU resource- intensive task is adding documents to the index. To ensure optimal CPU performance, it is not recommended to have more than 100,000 documents on a single server. Exceeding the 100,000 limit requires consideration of adding a dedicated server to the crawling process.

Disk Space

If a large number of documents will be stored on a server and added to the index, it is also important to monitor hard disk space. Storage requirements can be calculated based on the total number of documents available for searching, as well as stored within the workspace. When SharePoint is installed, approximately 150MB of disk space is consumed by the initial installation. This 150MB is incremented by approximately 50MB when the first workspace is created. Each time a workspace is added, you will need to add approximately 20MB. To calculate how much space is consumed by each document, you should consider the following formulas, depending on whether you are working with standard or enhanced folders.

Assuming you are working with standard folders, using a document profile with 10 properties, you will consume approximately 12KB for metadata storage, and 30 percent of the size of the document for index storage, in addition to the actual size of the document. For this example, assuming the size of the document is 2MB, our formula to calculate storage requirements is 12KB + (1.3 x 2MB).

For enhanced folders, we will use the same document profile, with 10 properties consuming 12KB of metadata storage for each version, 30 percent of the document size for index storage once the document has been published, and 100 percent of the document size for each stored version of the document. For this example, assuming the document size is 4MB, the following formula would apply: 12KB + (1.3 x 4MB). This is the default formula, assuming that the document has been checked in and approved, but has never been checked out. If, for instance, the document has been checked out, the formula would be calculated as follows : (# of versions +1) x (document size + 12KB) + (0.3 x size of document).

Index Growth

Another key planning consideration to closely monitor is the index growth, as indexes can scale rapidly depending on the document types added to the index. Many index parameters can be configured that may have an impact on the size of the index. For example, Microsoft Word and Excel files have less of an impact on indexes than text and HTML files. The dedicated search server that houses a crawling server's index requires twice the amount of free space on the volume before the initial index propagation occurs. Once the initial propagation is complete, the total size of the index must be available as free space. Lastly, the number of searchable words in the document also has an impact on the index size.

Log Files

In addition to the index growth, log files should also be managed. As a matter of best practice, log files should be limited to 25MB of disk space. Log files use transaction logging as well as circular logging.

The last physical component that must be managed carefully is the RAM. Planning the required amount of RAM is essential to ensuring optimal performance. Similar to CPU, the amount of RAM must be planned to accommodate the total number of documents in the workspace, as well as documents included within the index. Best practice advise is to plan for a server with a base RAM of 256MB. For each 100,000 documents added to the workspace or index, you will need to add 100MB of RAM.

Calculating how long it takes to back up a server can be done by first determining the size of the backup file. This backup file can be determined by calculating the size of the wss.mdb and the full-text index. In case you are wondering how long it takes to write a backup, you will first need to determine the speed of the hard drive. Most modern servers today (such as a 500MHz Pentium III with a RAID 5 disk array) write data at a pace of approximately 5MB per second. At this pace, a backup of 25GB would take approximately an hour . Depending on the speed of your particular disk subsystem, your performance may vary. Specific procedures for backup, restore, and duplication can be found in Chapter 13.


                 
Top


Special Edition Using Microsoft SharePoint Portal Server
Special Edition Using Microsoft SharePoint Portal Server
ISBN: 0789725703
EAN: 2147483647
Year: 2002
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net