Site Server - Detecting System Bottlenecks in Sites Using Site Server - Commerce Edition

Article
08/28/2007

September 1999

Introduction

If you manage a Web farm of computers running Microsoft Site Server 3.0 Commerce Edition, you can monitor system performance with Windows NT Performance Monitor or other similar tools to predict where bottlenecks are going to occur. Effective monitoring includes the following activities:

Run calibration tests
Test system capacity
Update user profiles
Monitor key performance counters

Run Calibration Tests

One of the first steps in understanding system limits is to run calibration tests during the development phase. Record the following results of the tests for each server for future use:

Size of available RAM
Maximum number of physical disk reads per second for each disk subsystem
Maximum number of physical disk writes per second for each disk subsystem
Maximum attainable network bit-rate

Test System Capacity

Test system capacity with the software you plan to deploy as soon as your code is reasonably stable and you have a solid user profile, site profile, and hardware architecture. System capacity testing should produce maximum transaction rates for each individual operation, thus essentially calibrating each individual operation. If testing is done properly, you can view system capacity as a percentage of the maximums determined during testing.

Update User Profiles

Actual user profiles will vary from the test environment, and code changes can significantly impact these numbers even after the system is deployed. When user profiles change, it is important to update them so they more closely match reality. Updated user profiles enable you to predict more accurately what changes need to be made in deployment.

Monitor Key Performance Counters

You can discover system bottlenecks by monitoring several key performance counters during peak periods. The following table describes the counters you should monitor. You can find the counters in the Microsoft® Windows NT® Performance Monitor. They will be distributed among the machines in the Personalization and Membership (P&M) service group. The counters in the System and Memory objects can be used to monitor capacity.

Object	Counter	Observation	Services affected
Network Segment	Bytes received per second	If a card approaches its maximum capacity, another should be added.	All
	Bytes sent per second
Inetinfo Instance in the Process object	Private bytes	Monitor this for memory leaks or size approaching maximum available RAM.	All
	Virtual bytes
	Working Set	Should be well within hardware available.
Memory	Available bytes	Should be greater than 4 MB.	All
	Pages/sec	Should be less than one per second.
Physical Disk	Disk Writes/sec	Combined, these two counters should be well under the maximum capacity for the disk device. To enable this counter, run diskperf –y from the command shell and reboot the computer.	All except dynamic directory
	Disk Reads/sec
SQL Server	IO transactions/sec	Indicates how much activity the SQL server actually performs.	Commerce, Membership Directory, Security
System	Context switches/sec	If this is too high, add another system or look for fixes from Microsoft.	All
	%Total Processor	Peak utilization can be 100%, but utilization should not be sustained at a level with which you are uncomfortable. All of the server elements can be scaled horizontally.
Web	Total connections	Actual number of users.	All except content deployment
	Get requests/sec
	NonAnonymous Users per sec	This is for the security user profile.	Secure systems
Active Server Pages	Requests/sec		Any Web server with dynamic content
	Requests executing	If this number is always greater than one (1), there could be a problem in an ASP page or object that is causing a request to hang.
	Request wait time	Should be very close to zero (0).
	Requests queued	There should not be a significant queue except at peak periods.
Site Server LDAP	Connection Current	If this number changes often, pooled connections are not being used wisely in the implementation.	Membership Directory, Dynamic Directory
	Static Add per second	Represents a new user, but is very expensive in disk costs on the SQL server.
	Static Modify per second	Expensive operation that costs the SQL server significant disk I/O.
	Static Search per second	Most searches are indexed in the SQL server, so this should be an inexpensive operation.
	Current Dynamic Object	If this number never drops, the timeout for user objects is too high.	Dynamic Directory
	Dynamic Add per sec
	Dynamic Modify per sec
	Dynamic Search per sec
	Dynamic Delete per sec
Site Server Authentication	Auto-Cookie Authentication Successes per second		Any secured Web server
	Clear Text Authentication successes per second
	DPA successes per second
	HTML Forms Authentication successes per second
	Requests served from cache	Shows good cache utilization in the broker object on the Web server.
Site Server Gatherer	Crawl in progress flag	Can help explain high levels of activity on the crawl server.	Search
	Documents successfully filtered rate
Site Server Indexer	Build in progress	Can help explain high levels of activity on the index server.	Search
	Number of documents	Should be managed so the space is well within the RAM limitation of the server.
Site Server Search Catalogs	Active threads		Search
	Average response time	Should be less than three seconds.
	Successful query rate
Site Server Content Deployment	Current Replications Total	Number of active replications.	Content Deployment
	Bytes Total/sec	Sum of the network activity generated by service.
	Files Sent/sec	Monitor to confirm that levels of activity match requirements for data concurrency.
	Files received/sec