Dashboard “Nugget” Window Changes

The client DLL that handles the presentation of the Dashboard is hard coded to alert the SQL database of changes in “nugget” windows.

Unfortunately, nothing can be done within the Presentation layer of the application to remedy this. Instead, we must prepare for such changes and scale accordingly. We also need to discourage this practice by the user community.

This change has a double-impact on the Dashboard Web Server. First, the same traffic as listed above is used to refresh the view after IE has been launched for the first time after a change. The backend server is equally affected as shown in the statistics listed on later pages. Second, the processes it takes to notify the Portal Subscription Server is also overhead to this process.

To determine the impact of such a load, we first need to determine the number of times we expect this setting to be used. In addition, we need to consider that the first window change on a dashboard creates twice as much server load as subsequent changes. Using random polls in various user communities, we estimate that each person will minimize or maximize two Web Parts per day. This number is probably high, we had to start somewhere!

Performance statistics show that 60 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 one second even under heavy load. Based upon these numbers and the tests taken with Microsoft Web Application Stress tools, the test server can handle 3600 “nugget” changes per minute based upon a one1 second update. 60 Seconds * Simultaneous Users = 3600 simultaneous changes per minute. This allows 216,000 nugget changes per hour and 1,728,000 per working day. Divide this number by the number allotted per user (two) and you can determine that this server will support ~800,000 users based on the requirements of two changes 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:

Again, based on the numbers and the expected updates per user, a dual or quad PIII should handle most network in regards to nugget changes.

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. In this scenario, the store.vbs on the local machine creates DAV calls to the Portal Subscription Server for access to the SQL database:

Performance statistics show that 6 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 one second even under heavy load. Based upon these numbers and the tests taken with Microsoft Web Application Stress tools, the test server can handle 360 content changes per minute based upon a 1 second update. 60 Seconds * Simultaneous Users = 360 simultaneous changes per minute. This allows 21,600 content changes per hour and 172,800 content changes per working day. Divide this number by the number allowed per user and you can determine that this server will support ~170,000 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.

Portal Subscription Server

This server represents the standard SQL-based Dashboard server. As we mentioned earlier, this server is normally affected by Dashboard refreshes. In actuality, this server is affected by three different Dashboard Activities:

Client Dashboard Refresh

ECMS has modified the factory and store engines to reduce server impact during dashboard loads and refreshes. The following chart details the specific activity of the Portal Subscription Server during such refreshes and dashboard loads (from cache.)

As you can see, the only activity on the server is the expected load created as a result of simulating hundreds of users on the LAN segment. The server itself is not touched by such requests. Based on the processing required to handle immense levels of network traffic, we estimate that a single backend server can support tens of thousands of refreshes. If the Portal Subscription Server was placed on another LAN segment, there would be no limit to the number of refreshes the server could handle.

Dashboard “Nugget” Window Changes

The client DLL that handles the presentation of the Dashboard is hard coded to alert the SQL database of changes in “nugget” windows.

Unfortunately, nothing can be done within the Presentation layer of the application to remedy this. Instead, we must prepare for such changes and scale accordingly. We will need to also discourage practice by the user community.

To determine the impact of such a load, we first need to determine the number of times we expect this setting to be used. In addition, we need to consider that the first window change on a dashboard creates twice as much server load as subsequent changes. Using random polls in various user communities, we estimate that each person will minimize or maximize two Web Parts per day. This number is probably high, we had to start somewhere!

Performance statistics show that 10 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 600 “nugget” changes per minute based upon a 1 second update. 60 Seconds * Simultaneous Users = 600 simultaneous changes per minute. This allows 36,000 nugget changes per hour and 288,000 per working day. Divide this number by the number allowed per user and you can determine that this server will support ~150,000 users based on the requirements of two changes 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:

Again, based on the numbers and the expected updates per user, a dual or quad PIII should handle most network in regards to nugget changes.