August 8, 2007 at 7:22 am
Hi,
we work with the Reporting Services of the Itanium Edition of SQL Server 2005. With some reports (only some) we have the problem that
very long time is needed for the processing of the report. I checked the ExecutionLog table in my Reportserver database and detected that
values in the column TimeDataRetrieval (TDR) or pretty slow, but them in the column TimeProcessing (TP) are very high.
Report1: TDR = 8304ms TP = 34377ms .
In other (most) reports the values are completely different
Report2: TDR 8336ms TP = 233ms
Now the most interesting thing: When I execute the same report on our test server which is a xeon machine (same data volume, no user workload)
I get the following results:
Report1: TDR = 5244ms TP = 11731ms
Report2: TDR = 4750ms TP = 163
The differences in TimeDataRetrieval (TDR) should be ok, because the machine is used by over 700 people
and so the response times of the Analysis Server database could differ.
Report1 and 2 do not differ too much in complexity. A few groupings, parameters and so on.
The Itanium machine is a 2 way dual core system with 16 Gigabyte RAM.
The Xeon machine is a 2 way xeon system with 8 Gigabyte RAM (32bit processors).
What is going on there? How could I optimize the TimeProcessing of Report1 on the Itanium machine? Which performance counters or tools should I use to go
deeper finding out where the problem is?
SK
August 8, 2007 at 8:02 am
Hi
Perhaps nOt really a direct answer to your question, but you can download here a sql dashboard for reporting services so you can monitor.
Which processors are you using ? It seems to me that pulling the report and having so much users is the problem.
Good luck;
El Jefe
JV
August 8, 2007 at 8:10 am
Hi El,
thanks for your fast feedback!
I know the dashboard reports and use them, but I'm not sure how to use them for monitoring SSRS. Could you please explain me how you ment this?
We use two Itanium dual core 2 processors.
The users are not concurrently using the system, it is a dedicated Data Warehouse System. I think we should have a maximum of 5 concurrently users in peak times. And this was not the case when I ran my tests.
Best regards,
Stefan
SK
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply