Measure SQL performance without using profiler

Question

Are there simpler ways to measure SQL performance in MS-SQL than using profiler?

I have been using this script I found on the internet and it gives me measurements, but I don't know how accurate it may be.

DECLARE @StartTime datetime;

DBCC DROPCLEANBUFFERS  -- Force data/index pages out of buffer cache for valid test
SET @StartTime = GETDATE() -- Measurement Starts  

-->Insert SQL CALL/Script here

-- Measurement Ends  
SELECT ExecutionTimeInMS = DATEDIFF(millisecond, @StartTime, getdate())
GO

Are there similar alternatives to get a quick and dirty, generally accurate pulse on the choices I'm making?

It has returned some surprising results, but I don't where to direct the surprise, at the test queries or the the test tool/script?

Answer 1

Here is my test setup:

DBCC DROPCLEANBUFFERS
DBCC freeproccache

SET STATISTICS IO ON
SET STATISTICS TIME ON

SELECT * FROM sys.all_columns

that gives you nice output (on messages tab):

(4307 row(s) affected)
Table 'syscolrdb'. Scan count 1, logical reads 167, physical reads 0, read-ahead reads 167, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 12, physical reads 1, read-ahead reads 10, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
   CPU time = 78 ms,  elapsed time = 738 ms.

Answer 2

Before dropping buffers you should set a checkpoint to force all dirty pages to disk. Anyway, dropping buffers may be a choice while playing at the test system. Performance of SQL queries largely depends on the data in the DB as well as the type, frequency, parameters and result sets of queries run on that DB.

Running queries on a "clean" single-user system produces results for the clean single-user system. Buffer management is a core function of a DBMS so i don't see a point in arbitrary flushing the buffers and measure an execution time value. In addition, doing that on a production system may likely decrease overall performance and therefore affect the query to be tested too.

To optimize a single query, use the execution plan and identify parts of the query which account for the highest share and see if you can do anything about it. For example, if you have ill designed indexes which do not fit your data, execution time will mean nothing but the execution plan will give you a hint.

To identify queries worth optimization effort use the profiler the find a) resource consuming queries (eg long running) and b) frequently used queries.

To monitor an overall system use the performance counters and have an eye on the memory and I/O subsystem, eg the paging counters.