Tuning Your Hardware
Choosing the correct hardware for the Web servers and SQL servers plays an important part in doing a performance analysis. A result of this work is to develop recommendations for appropriate hardware for other users.
Web Servers
The Web servers were given more than enough RAM to perform their task. We calculated the maximum working set for the server under load and thus determined how much we could lower the physical RAM in the server.
The disk subsystem of the front-end Web server is used as a read-only device for storing the boot partition and the site content. It needs a read/write device for the pagefile, but these operations are minimal given sufficient physical memory to support the system. The Web server does use the disk subsystem to write event logs and Web logs. This activity is well tuned by the operating system and rarely requires more than a single spindle for performance.
The network system on the Web server should consist of at least a single 100BaseT card. For improved security, manageability, and availability, the server should have two or even three network cards. The network throughput of the Web servers were not sufficient to saturate even a 100 megabit card.
Finally, the CPU and processing subsystem for the server should be the best currently available. This particular hardware subsystem remains the bottleneck on this server for the foreseeable future. This is due to the dynamic and process intensive nature of the ASP Web pages. This also makes sense given our current per-processor licensing scheme.
SQL Servers
Typically, on the SQL servers the most important tuning option is setting up the physical disk subsystem. For optimal performance, the databases should be separated from their transaction logs on different physical drives. All of the databases, transaction logs, and the TempDB should be set up so that the individual disk subsystem is not the bottleneck. In our test scenario, the physical disk subsystem was not an issue, but a real site should carefully correlate disk costs with the transactions in order to plan for increased disk requirements.
SQL Server takes advantage of large amounts of physical memory, so the amount of RAM available should be weighed against the working set of the database. During a runtime test the network I/O and the processing load on the SQL server will be a direct function of the number of front-end server accessing the SQL database as well as the profile of the load. In our testing we set up the SQL server so that it was not the bottleneck. Commerce Server 2000 is designed for horizontal scalability and partitioning of the back-end database systems. The databases for marketing, user profile management, catalog, data warehouse, transactions, and administration can be separated into physical SQL server databases. Thus, the deployed system can easily be distributed onto a separate server or cluster per database. Details of how to do this are not part of this discussion.
Copyright © 2005 Microsoft Corporation.
All rights reserved.