Database Performance Testing and Benchmarking

The database performance is quantity of job than can be executed per second or another period. The performance is usually measured in terms of set of metrics. Most important are response time latency, number of SQL statements (or transactions for OLTP systems) or another requests that can be executed per second, number of rows can be fetched per second.

The database server or solution benchmarking is a process of estimating a performance in order to find if the server or solution can serve enough client requests. At the other hand we have performance tuning and database performance comparison. The performance tuning goal is to optimize mentioned database metrics: minimize response time, maximize number of transactions per second, etc. The database performance comparison allows to identify best hardware configuration, software version or even database system for your solution.

DTM DB Stress is a database testing tool that measures the performance of database servers, server's hardware and server side of database solutions. It allows users to collect information about:

  • Database server (as software) performance: how many queries or transactions the server can run per second.
  • Performance of the server side of the solution, i.e. efficiency of procedures, triggers, indexes, rules, etc.
  • Operating system resource usage and loading: number of used threads, processes, handles, etc.
  • Hardware utilization at the server and client sides: usage of RAM, CPU, disk storage, etc.

An important product feature is capability with normal and stress activity of the clients. The stress activity is extremely large number of requests, huge data sets of another non-standard server or database application usage. In this mode the user of the software can find bottlenecks or even general server, database or solution limitations.

Use Case. SQL Server based solution performance testing

We have accounting solution based on Microsoft SQL Server database. Our goal is understand how many clients can work with our solution.
However, we have two limitations: response time must be less 0.5 seconds for typical transaction and our production server can be loaded by OLAP clients (up to 5 users at once) at the same time.

There are few steps to test performance in this case. The most complex is understand typical requests by real users to server side. We ran SQL Server Profiler and create two traces with SQL scripts: for our test users and for concurrent OLAP activities.

At the second step we create two tasks in DTM DB Stress: 'Test Client' and 'OLAP activity' and import trace files (.trc). Fr the second task we assign 5 concurrent users.

The last step helps us to view maximum duration in seconds for 'Test Client' task and find number of concurrent virtual users with acceptable response time.

See Also