Performance poor on SSRS vs same Query in SSMS
Hi all,
I have a SSRS Report that I call through a Report Action in a Cube. It is running Sharepoint Integrated mode (which i doubt is what causes my problem).
The report pulls from a relational dataset with 4 parameters. When i run the query from SSRS it takes < 1 sec. When i run the report from SSRS through a webbrowser (passing parameters) it takes serveral minutes.
I have tried serveral suggestions from posts in this forum to try and solve the issue - but nothing have worked so far. (se comments in the query below).
The call to the report looks like the following:
http://dwbitest01/ReportServer/Pages/ReportViewer.aspx?http://veritastest/Abonnement/SSRS_Rapporter/AboNummerUdtraek.rdl&omfatning_kode=12345&status=Bero&produkt_kode=EKT&dato=25-01-2011&rs:Command=Render&rs:Renderer=HTML5
The stored procedure that I use in the dataset looks like this:
CREATE
PROCEDURE [dbo].[AboNummer]
@omfatning_kode nvarchar(10)
=
'1234567'
,@status
nvarchar(25)
=
'Bero',
@produkt_kode nvarchar(25)
=
'JP',
@dato nvarchar(10)
=
'01-01-2011'
/* Default values added for performanceimprovement */
AS
BEGIN
SET
NOCOUNT
ON/* Added for performanceimprovement. */
/* Declare local variables for performanceimprovement to avoid "Parameter Sniffing". */
declare @OMF
nvarchar(10)
declare @STA
nvarchar(25)
declare @PRO
nvarchar(25)
declare @DAT
nvarchar(10)
set @OMF
= @omfatning_kode
set @STA
= @status
set @PRO
= @produkt_kode
set @DAT
=
@dato
SELECT
dm_abo_dim_abonnement.Abonnementsnummer,
dm_abo_dim_abonnement.fornavn,
dm_abo_dim_abonnement.efternavn,
dm_abo_dim_abonnement.abonnements_status,
dm_all_dim_tid.aar,
dm_all_dim_tid.uge_nr,
dm_abo_dim_produkt.produkt_navn,
dm_abo_dim_prisliste.omfatning_kode,
dm_abo_dim_prisliste.betalingsperiode_kode,
dm_abo_fct_abonnement_dag.antal,
dm_abo_dim_abonnement.koen_kode,
dm_abo_dim_abonnement.koen_tekst,
dm_abo_fct_abonnement_dag.status,
dm_abo_dim_prisliste.produkt_kode,
dm_all_dim_tid.dato
FROM dm_abo_fct_abonnement_dag
INNER
JOIN
dm_abo_dim_abonnement ON dm_abo_fct_abonnement_dag.dim_abonnement_id
= dm_abo_dim_abonnement.dim_abonnement_id
INNER
JOIN
dm_abo_dim_prisliste ON dm_abo_fct_abonnement_dag.dim_prisliste_id
= dm_abo_dim_prisliste.dim_prisliste_id
INNER
JOIN
dm_abo_dim_produkt ON dm_abo_fct_abonnement_dag.dim_produkt_id
= dm_abo_dim_produkt.dim_produkt_id
INNER
JOIN
dm_all_dim_tid ON dm_abo_fct_abonnement_dag.dim_dato_id
= dm_all_dim_tid.Dim_tid_id
WHERE
(dm_abo_dim_prisliste.omfatning_kode
= @OMF)
AND
(dm_abo_fct_abonnement_dag.status
= @STA)
AND
(dm_abo_dim_prisliste.produkt_kode
= @PRO)
AND
(dm_all_dim_tid.Dim_tid_id
=
CAST(SUBSTRING(@DAT,
7, 4)
+
SUBSTRING(@DAT,
4, 2)
+
SUBSTRING(@DAT,
1, 2)
AS
int))
OPTION
(TABLE
HINT(dm_abo_fct_abonnement_dag,
INDEX
(dm_abo_fct_abonnement_dag_QueryIDX)))
-- Added for performanceimprovement
END
Any ideas?
Thanks....
Jesper W
June 30th, 2011 3:35am
I see you dictate to SQL Server to use a specific index, any reason? Could be parameter sniffing... See some useful options http://pratchev.blogspot.com/2007/08/parameter-sniffing.htmlBest Regards, Uri Dimant SQL Server MVP http://dimantdatabasesolutions.blogspot.com/ http://sqlblog.com/blogs/uri_dimant/
Free Windows Admin Tool Kit Click here and download it now
June 30th, 2011 3:58am
Hi Uri,
Thanks for your reply.
The dictation of a specific index was a test for trying to solve the problem. It makes no difference if i use it or not - but i included it in my example to let you see what i had allready been trying.
I thougt i allready avoided "Parameter Sniffing" by declaring local variables (se begining of code). But maybe i am doing it wrong?
/ Jesper W
June 30th, 2011 4:46am
Hi JesperWittendorff,
From your description, the report takes more time to run in integrated mode then in native mode, right? Please correct me if my understanding is wrong.
Actually, reports render more slowly in integrated mode than in native mode. Please refer to the following reasons and hope it can help you.
1. The bulk of the time spent during report rendering is due to the number of HTTP calls between the Web Front End (WFE) and the Reporting Services servers. Integrated Mode results in more calls than Native Mode, which results in more overhead.
2. This
SQLCAT article concludes that, although there’s a 400 millisecond performance penalty expected in SP Integrated Mode, that SP Integrated Mode with SQL Server 2008 R2 ultimately outperforms Native Mode. We found the performance penalty to be far more
than a 1/2 second delay in our situation and therefore could not risk performance on existing and future client implementations.
The best solution at this time was to revert to Native Mode. After Microsoft reviewed HTTP traces, IIS logs, FREB analysis, SharePoint logs, PerfMon data, Profiler traces, and network analysis, they concluded the bulk of the time is being spent in the
Report Viewer control.
For more information about the topic, please refer to the following article,
what’s up with the Slow SSRS R2 Rendering in SharePoint 2010 Integrated Mode:
http://www.sqlchick.com/entries/2011/1/25/whats-up-with-the-slow-ssrs-r2-rendering-in-sharepoint-2010.html
IF you have any question, please feel free to ask.
Thanks,
Eileen
Free Windows Admin Tool Kit Click here and download it now
July 5th, 2011 3:10am
Hi All,
Thank you very much for your reply's.
Eileen: You are right - the report takes slightly longer in integrated mode. This is however not a big issue here so we are continuing in Integegrated mode.
I found out after doing a trace that i had an unused dataset in the reoport selecting distinct Status from the Fact table. Eventhough it was not used in the report - it was still running on report open. After deleting this dataset from the report the perfomance
is as expected.
Thanks.
Jesper W
July 5th, 2011 4:10am