High Performance 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
Editor's Notes
- #2: Take a screenshot!
- #3: Slow loading means Bad user experience Server stress
- #7: Make sure to SET NOCOUNT ON
- #8: Some scenarios, the SQL and SSRS server are the same machine
- #10: Check if 2008, 2012 need join(). 2016 doesn’t Older versions need to use JOIN() on your multivalue parameter if sending to a USP. 2016 doesn’t need it!
- #11: Combine with previous? IF/THEN WITH RECOMPILE
- #12: Defining page breaks, setting expressions in header/footer (whole thing has to render), subreports in tablix, anthing that’s RBAR Maybe do a demo slide comparison of this?
- #15: MAke usre all subreports don’t run