SQL Server Reporting Services (SSRS) is an easy-to-use tool for automating reports and creating highly visual dashboards. Although SSRS is easy to learn there are many tips and tricks that can improve your report building experience, not to mention make your reports run blazing fast! This rapid-fire session goes over my learnings from the past six years of developing high performance SSRS reports, including topics like multivalue parameter efficiencies, how to best utilize subreports, and performing SQL CRUD operations with SSRS.

1. High Performance SSRS:
Lessons Learned
GroupBy | Bert Wagner | January 13, 2017

2. 2
These are our enemies!

3. Background
● BI developer at Progressive Insurance for 6+ years
● Primarily SQL 2008, 2012
● Will be using StackOverflow data dump
● Slide, demos, code is available on GroupBy.org and
bertwagner.com
3

4. Overview
1. SSRS Usage Data
2. SELECT *
3. Traffic and Specialization
4. Multivalue Parameters
5. Dealing with Parameter Sniffing
6. Explicitly Defining Property Values
7. Stored Procedure CRUD Operations
8. Dynamic SQL
9. Subreport Switching
denotes demo in SSRS/SQL
4

5. 1. SSRS Usage Data
● Important to be able to measure results
○ Only way to solve “it depends” answers
● SSRS database has built in logging for analysis
○ https://msdn.microsoft.com/en-us/library/ms159110.aspx
● Most useful metrics to look at when measuring performance:
○ Time Data Retrieval - time getting the data for report
○ Time Processing - time manipulating the data in report (sort, filter,
etc…)
○ Time Rendering - time to build the report in the chose render
format (HTML, Excel, PDF, etc…)
5

6. 2. SELECT *
● Brings back more data than you actually need
● Indexes suffer/hope you like table scans
● Maintainability - new columns might force changes in datasets
○ Duplicate column names might break reports
○ Overtime extra columns might be brought in that aren’t needed
● Doesn’t tell future developers anything about intentions
6

7. 3. Traffic and Specialization
SQL
Database
SSRS
Server
User’s
Computer
Scenario #1: No work in the query, lots of work in the report. Work
includes filtering, sorting, etc…
7

8. 3. Traffic and Specialization
SQL
Database
SSRS
Server
User’s
Computer
Scenario #2: Filtering, sorting in the query, reporting server just displays
the page to the user
● No filtering in the dataset
● No sorting in the tablix
8

9. 4. Multivalue Parameters
9
● Multivalue parameters can be handled multiple different ways
○ Some are more performant than others!

10. 5. Dealing with Parameter Sniffing
10
● Parameter sniffing occurs when differing values in the input parameters
cause a sub-optimal execution plan to be chosen
● Due to the nature of SSRS report parameters, parameter sniffing is a
common problem
● Solutions:
○ WITH RECOMPILE
○ OPTION (RECOMPILE)
○ OPTIMIZE FOR
○ IF/THEN

11. 6. Explicitly Defining Property Values
11
● Any report properties not explicitly defined during render have to
determined by SSRS during the processing and render steps.
● Explicitly define properties like:
○ Text alignment (don’t use General)
● Some properties have to do lots of calculating which hurts performance:
○ AutoGrow, AutoShrink
○ Image AutoSize
A full list of properties and considerations can be found here:
https://technet.microsoft.com/en-us/library/bb522806(v=sql.105).aspx?f=255&
MSPPError=-2147217396#Render

12. 7. Stored Procedure CRUD Operations
12
● It is possible to INSERT/UPDATE/DELETE on the database from an
SSRS report
○ Can actually do anything that a stored procedure will allow
● There are a few things we exploit to get this to work:
○ Datasets in a report always execute - even if they call a stored
procedure that inserts/updates/deletes and returns no data
○ If the data source’s “single transaction” property is enabled, datasets
will execute in the order they appear

13. 8. Dynamic SQL
13
● Dynamic SQL is a query that is built
programmatically
○ This gives us lots of flexibility in
terms of how we can display our
data and build reports so they are
reusable
● Dynamic SQL can run very efficiently or
have terrible performance - use caution
and ALWAYS test
● Dynamic SQL also leaves lots of room
open for SQL injection - be sure to
parameterize any user input you are
building into your query

14. 9. Subreport Switching
14
● Reports with lots of expressions
generally take a long time to render
● If a report is using a lot of
expressions, it’s sometimes possible
to break them up into multiple
subreports
○ The parent report decides which
subreport to run (based on
efficiency)
○ This comes up a lot if you are
displaying data using dynamic
SQL

15. Thank you!
● Session: https://GroupBy.org/go/session6
● Blog: https://bertwagner.com
● Email: bertwagner@bertwagner.com
● Twitter: @bertwagner
15