You're out cruising Main Street on a Saturday night in your slightly dated but still very nice 2000

model. At the light, up rumbles a shiny new 2005 model. It's got all the cool new features: CLR-integration, T-SQL enhancements, table partitioning. You call to the driver, "Nice car. What'll she do?" Slick new features are cool, but how fast is it? In an OLTP environment, features are interesting, but speed is king. To that end, I built a test of OLTP-like activity to measure the performance difference between SQL Server 2000 (SP3a) and SQL Server 2005 (April CTP). The system I used for the tests was a single-CPU desktop (2.66 GHz P4) running Windows Server 2003 with 2 GB RAM and an 80 GB IDE drive. Start twelve osql (2000) or sqlcmd (2005) processes. Each process runs the same script. Sleep ten seconds (so all processes can make connections) Loop 10,000 times Insert records into each of two tables to load up test data (think order and orderitem) End loop Loop 10,000 times Loop five times Read a random record from table 1 by its bigint primary key Read a set of records for a random five millisecond time period by an indexed datetime column End loop Update a random record in table 1 Update a random record in table 2 End loop There is a small amount of delay built in (one second every three UPDATE/SELECT loops on each process). Without the delay, the CPU runs 100% continuously.

Well, the guy in the 2005 model blasted to the next stoplight in 18.5% less time than it took you, and he wasn't even working as hard as you were. Average Elapsed Time (hh:mm:ss) SQL Server 2000 SQL Server 2005 Difference Percentage 1:23:5 5 1:08:2 5 0:15:3 0 18.5%

CPU Usage History Graphs

Script Start - SQL Server 2000

Script Start - SQL Server 2005

Steady-state Update/Select - SQL Server 2000

Steady-state Update/Select - SQL Server 2005 Some interesting points: • • • • I built this script without any expectation of how the results would come out. Nothing in it is meant to lean specifically toward 2005's strengths. These tests were run on exactly the same hardware. The test script is straight T-SQL and stored procedures. It does not use any 2005-specific capabilities. In the steady-state update/select section, the CPU never spikes using 2005. If you've seen that sustained 100% spike on SQL Server 2000 production systems, you will especially look forward to a more stable system with 2005.

There are dozens of other bits of information that you might want to capture in a test like this. I chose the two that I thought were most significant: elapsed time and CPU usage graphs. There are also many different scenarios that could be tested, but I wanted to finish my testing sometime before Microsoft shipped the product.