MOSS Server Performance Considerations
MOSS Server Performance Considerations taken from Optimizing Office SharePoint Server for WAN environments and my experiences
Recommendation: use x64 hardware on all servers to optimize page downloads by minimizing number of round trips between client computers and server computers.
Reason: With x64 you are not limited to 2 GB of Memory.
Benefit: Reduces network traffic and latency due to FE servers hitting the memory limit and needing to recycle.
Recommendation: apply Windows Server 2003 SP2
Reason: A list of all of the reasons can be found here: https://support.microsoft.com/kb/914962/en-us
Benefit: Optimizes the Front End server’s performance
Recommendation: Defragment the Front end Server’s drives
Reason: best practice for optimal disk performance
Benefit: Optimizes the Front End server’s performance
Recommendation: apply MOSS SP1 and post SP1 rollup fixes
Reason: The service packs addresses a lot of the known bugs that currently exist.
Benefit: Reduces network traffic and latency due to FE servers hitting the memory limit and needing to recycle.
Recommendation: Use a dedicated FE crawl target that is not in NLB (i.e. NLB is not installed)
Reason: By default, Office SharePoint Server 2007 uses all Web servers to crawl content in the server farm. When your server farm is configured to use all Web servers for crawling, the index server sends requests to each Web server in the farm.
Benefit: Crawling content in your farm places a heavy load on the Web servers. This tends to cause spikes and surges in network traffic, and is CPU-intensive and memory-intensive. By pointing to a dedicated FE server, users aren’t impacted negatively.
Recommendation: All server computers in the farm are on the same network segment. There is no switching in routers at the data layer. The network link between a Web server and the database server is less than 1 milliseconds (ms) latency and located 10 or fewer miles from the database server.
Reason: Routers and switches will increase latency even if the network connection between these is very fast. If the type of load the Web server is serving is some subset of user browse requests, we expect Office SharePoint Server 2007 to tolerate some latency between the Web server and the database server. On the other hand, pages with many or custom Web Parts, Stsadm commands, and search crawls are likely to fair less well.
Benefit: Reduces latency and provides a better experience for users in remote geographic locations
Recommendation: Do not use web gardens and BLOB cache at the same time
Reason: Because only one process can acquire the lock necessary to manage the cache, successful use the cache depends on which thread services a request. If a Web garden that does not have the BLOB cache lock services a request, the content it sends in response will not have caching directives associated with it.
Benefit: Reduces the amount of requests and data sent over the network by allowing BLOB Caching to work.
Recommendation: Optimize Blob Cache by including most used file extensions and increasing the cacheabilty value
Reason: The BLOB cache enables you to configure caching directives that are associated with items served from publishing site lists, for example, the Pages library and Site Collection Images. When the browser on the client computer encounters a caching directive, it detects that the item it is retrieving can be saved locally and does not need to be requested again until the caching directive expires. When the BLOB cache is turned on, a couple of different things happen. First, each time a cacheable item is requested, MOSS searches the hard disk drive of the Web server that received the request to see if a copy exists locally. If it does, the file is streamed directly from the local disk to the user. If it isn't on the local disk yet, a copy of the item is made from the SQL database where it is stored, and then the item is sent to the user making the request. From that point forward, all requests for the item can be served directly from the Web server until the item's cacheability value indicates that it has expired. The other thing it does is append a cacheability header to the item when the item is sent to the client. This header instructs the browser how long the item should be cached. For example, if a picture had a cacheability value of three days, the browser uses the copy of the image it has in its local cache if the picture is requested again within the next three days; it does not request it from the server again.
Benefit: That results in better performance in the server farm by reducing contention on the database server. In a geographically distributed environment, this is critically important because it reduces the number of items requested and sent over the network.
Please note that you need to ensure that the “Office Sharepoint Server Publishing” feature is activated on all Publishing sites. Also, you should update the location to the best performing drive, add in extra paths, and add in the max-age to expire based on your situation. For example:
Current setting: <BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>
Example Setting: <BlobCache location="E:\blobcache" path="\.(gif|jpg|png|css|js|htc|)$ " maxSize="10" max-age="86400" enabled="true"/>
Recommendation: Optimizing IIS Compression by changing the level of IIS compression from 0 to 9 and adding in certain dynamic files
Reason: When MOSS is installed, setup configures IIS to compress the static file types .htm, .html and .txt; it compresses the dynamic file types .asp and .exe. After a site has been hit by a few users, you can verify that compression is working by viewing the %WINDIR%\IIS Temporary Compressed Files directory on a Web server. It should contain multiple files, which indicates that static files have been requested and IIS has compressed a copy of them and stored them on the local drive. When that file is requested again, whether it's the same user or not, the compressed version of the file is served directly from this folder. Dynamic files can be compressed as well, but they are always compressed on the fly; copies are not kept on the local Web server. It may be advantageous to compress additional file types. For example, it probably makes sense to also compress the static file types .css and .js; it may also make sense to compress the dynamic file types .axd and .aspx.
Benefit: The IIS Compression can result in significant bandwidth savings. For example, the core.js file is included on every SharePoint page. When it's uncompressed, it is 257 KB; after compression, the file is only 54 KB without performing additional tuning to IIS compression.
Please note: Before applying IIS Compression, you will need to ensure that you only include files that are well-suited to being compressed. For example, .jpg files are not a good candidate for compression because the file format is inherently compressed already. Also, 2007 Microsoft Office system file types such as docx, xlsx and pptx are not a good choice for compression because the files are not served directly from the server; instead, they are routed through the different ISAPI filters that are used to manage the rich integrated end user experience for Microsoft Office content. In addition, in the 2007 Microsoft Office system, these file types are inherently compressed.
Comments
Anonymous
January 01, 2003
I've had a case open for a long time in regards to blob caching not functioning properly under MOSSAnonymous
January 01, 2003
Una cuestión que siempre me ha preocupado respecto a las bibliotecas documentales : ¿cada vez que seAnonymous
January 01, 2003
Una cuestión que siempre me ha preocupado respecto a las bibliotecas documentales : ¿cada vez