If you are not familiar with the concept of a Digital Dashboard, it is a platform for knowledge management. It is based on Microsoft Backoffice products such as SQL, Exchange and Windows 2000 Server. A dashboard is a customized page that provides a collective view of information such as email, calendar events, group calendars, intranet sites and even pivot tables and other office components.

The idea is that with a collective view of data, knowledge workers can make more informed decisions. Microsoft has released the Digital Dashboard Resource Kit (DDRK) 2.0 to provide companies with the tools required to quickly build their own customized dashboard components called Web Parts. The reusable components are then “published” so that end users can pick and choose the components they wish to use. The DDRK also contains some sample Web Parts that can be used out of the box.

DDRK 1.0 provided dashboard components for Outlook 2000. These components would allow the user’s Outlook Today page to use a Digital Dashboard. By replacing the user’s Outlook Today page with a detailed dashboard, users could instantly view all of their specific information such as email, tasks as well as intranet Web Parts such as department financials and Internet Web Parts such as traffic-cams or stock quote. The beauty of this is the simple fact that all of these developed Web Parts are absolutely reusable.
The DDRK version 2.0 provides browser Dashboards. Intranet sites can be constructed by users based on the information they wish to use. Dashboard designers publish the Web Parts. Users can incorporate the parts into their personal page using simple tools. In fact, because digital dashboard applications incorporate so many familiar features, users can learn to use them quickly. Users can actually move Web Parts on a dashboard using a drag-and-drop operation.

There are several flavors of Dashboard configurations. This paper focuses on the scalability of SQL Dashboard configurations.

Digital Dashboard Services Component

We should spend a minute to talk about the Digital Dashboard Services Component. In a sentence, it is a hidden, client-side component that is included in every dashboard page. The services component is what makes Web Parts reusable by providing a standard infrastructure for the following services:

• Part discovery - allows Web Parts to discover other Web Parts on a dashboard.
  
• Notification - allows Web Parts to respond to external events that occur at the dashboard or Web Part level.
  
• Session state management - allows Web Parts to interchange information and objects within a browser session.
  
• State management - allows dashboards and Web Parts to maintain global state and to persist this state between activations.
  
• Item retrieval - allows Web Parts to retrieve and maintain the state of items in the store module.
  

Microsoft Recommended Installation

The SQL Server sample digital dashboard stores Web Parts and digital dashboards in a SQL Server database. This sample dashboard includes a special IIS extension supporting the HTTP 1.1 and WebDAV methods that handle HTTP requests for dashboard contents that are compatible with Exchange Server and Microsoft Office.

Before you install the SQL Server sample digital dashboard, you should create an empty SQL database to store your dashboard resources. During installation, Setup adds tables, stored procedures, and triggers to the database you specify.

You must install the SQL Server sample digital dashboard on a computer running SQL Server version 7.0 or later, Windows 2000 Server, and IIS 5.0. The SQL Server Web Part catalog server, the catalog database, SQL Server, and IIS must reside on same computer. The instructions indicate that you cannot distribute these components across multiple computers. (We will show you later how to do this.)

To install the SQL Server sample digital dashboard, choose Install the Microsoft SQL Server Sample Digital Dashboard from the Building Digital Dashboards page of the Digital Dashboard Resource Kit. You can also run DDRK_SQL.msi from the CD-ROM. An installation wizard guides you through the process.

During installation, the wizard will prompt you for the following information:

• The name of the SQL Server and an authentication mode.
  
• The name of the Web root that users will use to attach to a dashboard. The Dashboard Factory files will be stored in the Web root that you specify. The default virtual root name is Dashboard, on the default Web Site server.
  
• The name of the Web root that will be used to access the catalog. The default name is sqlwbcat.
  
• The name of the database. You must specify an existing database.
  

Your responses are recorded in the IIS Metabase and used by the catalog server to locate the dashboard and database. If you modify virtual root directory names, or the database name and location, you should reinstall your software to update the IIS Metabase settings.

Addressing Scalability

The proposed solution as listed above offers substantial scalability problems. Each and every time a user loads, changes or otherwise views data on their dashboard, the Dashboard server is contacted and Web Server methods are used to spawn SQL Batch requests. A simple refresh from a single user puts at least 14K on the network and spawns at least 16 Web Server method requests. These requests send over 80K of data to the next tier where no less than 10 SQL Batch requests are sent.

Processor load is the primary bottleneck in this scenario. In our example, we used a Pentium II 500 MHz server with 256MB of RAM. The deltas shown below identify different cached loads on the same server: 1 User, 2 Users, 5 Users, 20 Users, 100 Users, 500 Users and 1000 Users.

As you can see from this graphic, 20 simultaneous users can and will adversely impact a single server using the hardware stated above. Moreover, Microsoft indicates that the information contained in the SQL server can not be replicated to other servers. The loads listed above are nothing more than refreshes of the same page; the equivalent of pressing F5 on the browser to refresh the data. Invoking a refresh, minimizing or maximizing a pane as well as changing the dashboard Web Parts impacts the SQL servers. Using the Content button to change the Web Parts impacts the SQL server much more than listed above.

This single-server solution offers no recovery or redundancy features. There are also no scalability options other than directing different groups of the user community to different Dashboard Servers.

This solution can easily be deployed with simple DNS entries. While DNS solves some of the scalability problems, it does nothing to provide recovery or redundancy. Based on processor performance, I recommend that no more than 750 users be placed on a single Pentium II, 500mHZ machine. Here is what we concluded:

My project team estimated that each person would refresh his or her dashboard once every fifteen minutes We know that with the CPU used in the test, 25 concurrent refreshes overload the CPU. This “overload” factor calculates to 150 refreshes per minute because of the duration of the session and variable load Multiply 150 and 60 to see the allowable refreshes per hour. Take this number and divide it by the number of refreshes per hour per user (four) and you get 2,250 users per server. This number is probably high as we are anticipating pushing this server HARD. So what does this mean for overall scalability? Here are our estimates based on the collected data:

A company with a 35,000 user population would require at least five Quad Processor servers. Obviously, this is not acceptable as these servers would be hit hard throughout the day and would need to be dedicated to serving Dashboard data. Another point to note is the launch of the Dashboard. One hundred simultaneous launches would cause serious delays.

Digital Dashboard Tiers

Before we discuss solutions, lets take a look a deeper look at the dashboard itself. The Digital Dashboard program is a combination of several components. By building the technology in layers, Microsoft can allow several different technologies to serve as subscription and storage servers including Exchange 2000, SQL Server and the Windows 2000 File System. Each tier is uses ASP and VBS scripts that can be modified to some extent

We found it interesting that the Middle and Data tiers use the same server, so we began looking at the dashboard factory and store modules to see if the systems could be modified. The goal is to separate the functionality of the dashboard to ease the server load and to provide an alternative to SQL server for the dashboard cache. To do this, we must change the Store processes to accept an alternative store. We also need to find a way to reduce the number of times the user hits the SQL server.