Client Content Change

This portion of the application tiers is also unavoidable. The clients must execute these changes on a SQL server when SQL Dashboard configurations are involved. This process begins when the user clicks the Content icon to launch the menu as indicated to the right. This screen allows the user to add or remove web parts from the Dashboard.

Statistics on this matter are much worse, but we expect the users to change these settings much less. These figures represent the hardest any server gets hit during any part of the dashboard process:

Performance statistics show that 3 simultaneous changes to the window size pushed the test machine to nearly 100% processor utilization. Based upon these numbers, we can apply some math:

The longest an update string lasted was 1 second even under heavy load. Based upon these numbers and the tests taken with Microsoft Web Application Stress tools, the test server can handle 180 content changes per minute based upon a 1 second update. 60 Seconds * Simultaneous Users = 180 simultaneous changes per minute. This allows 10,800 content changes per hour and 86,400 content changes per working day. Divide this number by the number allowed per user and you can determine that this server will support ~84,400 users based on the requirements of one change per day.

This math was based upon the test server running a single Pentium II-500Mhz processor. Simultaneous users would scale up based upon the processor on the Portal Subscription Server:

In each of these performance charts, remember that the information is assuming that the above listed users are executing the same process at the exact same time. Also remember that the only thing affected by delays will be the user session during time of update. SQL commands will stack as well as the IIS calls. Users should see no errors during such delays. For example, if 500 people update their content at the same time, the SQL server will run at 100% processor until each SQL and IIS request is fulfilled.

Sample Solution

Based on a large central population of ~35,000 users, ECMS recommends the following configurations at a minimum.

A single protected server to be used as the Dashboard SQL server is placed within the environment. At least two fairly new servers are to be configured as load-balancing web-servers. These servers should receive the ECMS Dashboard updates and point to the Portal Subscription Server as the portalserver. The weak link in this picture is the backend server so precautions should be made to protect and recover this server. Replication of the cache directory should provide redundancy in the user dashboards. Regular SQL backups should be able to cover and recovery issues with the SQL tables.

Disk space should be fast SCSI III or better. Capacity on the Dashboard Web Servers should include enough space to provide 35,000 with cached copies of data or roughly 286 MB. The SQL should be built to support twice as much data or 858MB. This should allow enough room for the structured data and log files.

Performance Testing Reference

All tests were performed on an isolated network. Servera acted as a NAT portal to the Internet. Server1 acted as the primary Dashboard Server. Servers A and B acted as front end servers for code tests and all machines (with the exception of server1) acted as clients in order to test simultaneous connections to the dashboard servers.

Performance monitor was used to gather logs on each of the servers. Tests were phased to determine loads based on different concurrent sessions:

1 User These tests were easy to accomplish with a single client workstation
2 Users These tests were easy to accomplish with a two client workstations
5 Users These tests required a couple of extra people and all machines
20 Users These tests required traffic load generators
100 Users These tests required traffic load generators
500 Users These tests required traffic load generators
1000 Users These tests required traffic load generators

To generate simulated loads, we downloaded the Microsoft Web Application Stress tool. By using the record function, we can record the specific items we want to simulate at higher levels. On many of the tests, we had to enable Anonymous access to the Dashboard sites.

Reference

White Paper- “Building and Deploying Digital Dashboards”, Microsoft
White Paper- “Digital Dashboard Overview”, Microsoft
White Paper- “Digital Dashboard- Business Process Assessment Guide”, Microsoft
White Paper- “Microsoft® Windows NT® Product Group High Availability Operations Guide”, Microsoft Consulting Services
Book- “Windows 2000 Server: Planning and Migration” ,New Riders Publishers
TechNet Article- “Chapter 10 - Measuring Multiprocessor System Activity”, Microsoft
TechNet Article- “MS SQL Server Scalability”, Microsoft
TechNet Article- “Part 2 - Planning and Deploying Your MS SQL Server Solution”, Microsoft
TechNet Article- “Internet Information Server 5.0 Resource Guide”, Microsoft

© Copyright ECMS, Inc., 2000