Restoring the Database During Benchmark Testing

When you performance-test an application under varying user loads, test conditions must be the same for each test. If your test modifies the application's underlying database, you need to restore the database to its initial state before the next test iteration. A database application performs best when it can access data from the database server's cache (without needing to physically read the data from disk), so initializing the database cache is also important. You can initialize a database in several ways; I wrote several fairly simple scripts.

In Quest Software's Benchmark Factory Visual Control Center (VCC), you can specify a script of your own for Benchmark Factory to run before each iteration of a test. As soon as the script is complete, the test begins. However, before the test started, I wanted to run my series of initialization scripts.

The script that I wrote to initiate the test process is fairly simple. First, the script uses the Microsoft Windows 2000 Resource Kit's Soon command to schedule another script to run on the server. I chose Scheduled Tasks under My Computer to configure the AT Service Account for the server's command scheduler (i.e., the security context that scheduled jobs will run under) to an account that has the authority to access all the resources the script requires. Next, the Benchmark Factory script uses the resource kit's Waitfor command to wait until the test server signals its readiness to proceed with testing.

My scripts' primary task is to restore a Microsoft SQL Server database. Because the test I was running was an IIS application that used SQL Server 7.0 for data services, my first script began with the Net Stop command to stop the IIS service (i.e., the World Wide Web Publishing Service). To ensure that all database activity had a chance to stop, I used the resource kit's Timeout command to pause the script for 20 seconds. (The Timeout utility combines the Wait command's ability to wait for a specific length of time with the Pause command's ability to cause the script to continue when you press Enter.) Next, the script used the SQL Server 7.0 OSQL utility to restore the test database from a disk backup. The final step in the script used the resource kit's Shutdown utility to shut down and restart the test server, ensuring that the server as a whole was in a known repeatable state.

My script to restore a Microsoft Exchange Server database was similar. After stopping Exchange Server's Information Store (IS) service, the script copied an offline-backup version of the initial-state priv.edb file (overwriting the "used" copy), then ran Exchange Server's Isinteg­patch utility and restarted Exchange Server services.

The test server needed to run another script after it rebooted. To accomplish this, I configured the test server to automatically log on a user I created for the test. For security reasons, I don't recommend this procedure on a production network; however, it's useful in a physically secure, isolated lab network. The Microsoft article "How to Enable Automatic Logon in Windows NT" (http://support.microsoft.com/support/kb/articles/q97/5/97.asp) describes the Registry entries necessary to configure an NT system for automatic logon. The Microsoft article "How to Enable Automatic Logon in Windows NT" (http://support.microsoft.com/support/kb/articles/q253/3/70.asp) covers Win2K systems. I like to create a script that uses the resource kit's Reg utility to automate these Registry updates. According to the Microsoft article "Bypassing Automatic Logon in Windows" (http://support.microsoft.com/support/kb/articles/q114/6/15.asp), you can hold down the Shift key during logon processing to force the system to bypass automatic logon—a capability you'll need sooner or later (e.g., if you want to log on a different user ID to run a different logon script or to avoid running the auto-logon user's logon script).

My last script ran as the logon script for the user ID I configured to automatically log on. Because the automatic logon can occur before some system services (e.g., MSSQLServer) have completed their startup processing, the script begins with the Timeout command and waits 75 seconds to be sure that SQL Server is ready to work. The script's next step uses SQL Server's OSQL utility to run several SQL Select statements, effectively preloading SQL Server's cache with data. Finally, the script runs the resource kit's Waitfor utility with the option that tells the VCC to proceed. The preiteration script running in the VCC is now completed, and the benchmark test runs.

Although this process isn't simple or straightforward, it worked. And it certainly beat performing everything manually. On the Windows 2000 Magazine Web site, you'll find sample code that demonstrates these scripts. Go to http://www.win2000mag.com/ and enter InstantDoc ID 15444.