June 12, 2018 at 6:22 am
Hello,
We migrate reports from a SSRS2012 Instance with Sharepoint integration to a SSRS2016 Instance in native mode and we encounter some issues with one report.
The first issue is the time to show the report, on sharepoint SSRS2012 environment the report is shown after about 20s, on native SSRS2016 the report is shown after 10min.
On server side the execution time is the same for the 2 environments, less than 2s, so it's the rendering on client which take the time.
I notice that SSRS2012 render the report in HTML4 format by default, instead of HTML5 for SSRS2016.
If I force the HTML4.0 format in SSRS2016 the time get down to about 20s to render as before but we would want keep HTML5 by default.
Is there an explanation why HTML5 render is so long ? (tested in different browser, IE11, Edge, Chrome, Firefox with always the same difference)
Another issue in the HTML5 render is some data have vanished from report, the data are present in the HTML source but not visible in the rendering ?
The report is table with about 4000 rows (without paging) and 2 rowgroup, a parent row with aggregated data and child rows with detailled data, the missing data are only on child rows (and not all).
Our SSRS2016 instance is in SP1 version without CU installed.
Any idea to solve my problem is appreciated.
June 13, 2018 at 4:38 pm
Julien Maillard - Tuesday, June 12, 2018 6:22 AMHello,We migrate reports from a SSRS2012 Instance with Sharepoint integration to a SSRS2016 Instance in native mode and we encounter some issues with one report.
The first issue is the time to show the report, on sharepoint SSRS2012 environment the report is shown after about 20s, on native SSRS2016 the report is shown after 10min.
On server side the execution time is the same for the 2 environments, less than 2s, so it's the rendering on client which take the time.
I notice that SSRS2012 render the report in HTML4 format by default, instead of HTML5 for SSRS2016.
If I force the HTML4.0 format in SSRS2016 the time get down to about 20s to render as before but we would want keep HTML5 by default.Is there an explanation why HTML5 render is so long ? (tested in different browser, IE11, Edge, Chrome, Firefox with always the same difference)
Another issue in the HTML5 render is some data have vanished from report, the data are present in the HTML source but not visible in the rendering ?
The report is table with about 4000 rows (without paging) and 2 rowgroup, a parent row with aggregated data and child rows with detailled data, the missing data are only on child rows (and not all).
Our SSRS2016 instance is in SP1 version without CU installed.Any idea to solve my problem is appreciated.
Are you comparing these from the ExecutionLog3 view? Hopefully...and in that case there is also the additional_info xml column that has additional rendering information. Some of those are explained further in this article - uses the older ExecutionLog2 view but the explanations are the same:
ExecutionLog2 View – Analyzing and Optimizing Reports
Sue
June 15, 2018 at 2:51 am
Yes I get the stats from ExecutionLog3 view, TimeDataRetrieval:528, TimeProcessing:245, TimeRendering;43, Status:rsSuccess, in the additional info there is nothing suspicious.
But the report is shown after 10min, and the user browser consume 100% CPU load, the issue come from the rendering for the long duration wait to show the report.
For the missing data, I check the html source code to find the difference between HTML4.0 and HTML5 render, in HTML5 there is a css class added which prevent the text showing.
HTML4 render for the cell :<td style="min-width: 34.93mm;WIDTH:38.10mm;" class="Ac99b6ab8de5741758811de1644f736ba291c">
<div style="HEIGHT:4.43mm;overflow:hidden;">
<table cellspacing="0" cellpadding="0" border="0" class="Pe633e5af0e0842feaafed057ce91434b_1_r17" lang="en-US">
<tbody>
<tr>
<td style="word-wrap:break-word;white-space:pre-wrap;font-style:italic;color:DimGray;" class="Ac99b6ab8de5741758811de1644f736ba291" alt="Sample data" title="Sample data">Sample data</td>
</tr>
</tbody>
</table>
</div>
</td>
HTML5 render for the same cell :<td style="word-wrap:break-word;word-break:break-word;white-space:pre-wrap;" class="Ac3b81efd5e454266b2496e6d76f16768291c">
<div style="width: 35.28mm; min-width: 35.28mm; overflow: hidden;">
<div class="P02b7ecd1286c4470a443720c14b26c37_1_r17 tdResizable" lang="en-US" style="width:100%;display: -ms-flexbox;display: -webkit-flex;display: flex;-ms-flex-flow: row;-webkit-flex-flow: row;flex-flow: row;">
<div style="word-wrap:break-word;word-break:break-word;white-space:pre-wrap;font-style:italic;color:DimGray;" class="Ac3b81efd5e454266b2496e6d76f16768291 cannotGrowTextBoxInTablix cannotShrinkTextBoxInTablix" alt="Sample data" title="Sample data">
<div style="width:35.28mm;min-width: 35.28mm;">Sample data</div>
</div>
</div>
</div>
</td>
If I remove the "cannotGrowTextBoxInTablix" class from the container, the text is correctly displayed, but I don't know how block this class in the report design.
For the performance issuc I have an acceptable work-around : activate paging on the report.
June 15, 2018 at 3:32 am
After posting the preceding post, I have found the solution.
In the report design, when I click on the text zone of the cell, there is a property "CanGrow" which was set to false. I change the setting to true and it solves my problem 🙂
For the performance issue the paging has also solved my issue, but I would like to know why the HTML5 render is 30 times longer than HTML4 to show a table of about 4000 rows.
June 15, 2018 at 10:50 am
Julien Maillard - Friday, June 15, 2018 3:32 AMAfter posting the preceding post, I have found the solution.
In the report design, when I click on the text zone of the cell, there is a property "CanGrow" which was set to false. I change the setting to true and it solves my problem 🙂
For the performance issue the paging has also solved my issue, but I would like to know why the HTML5 render is 30 times longer than HTML4 to show a table of about 4000 rows.
The render time isn't bad in SSRS so maybe it's after SSRS is done with it's part and it's passed back to http.sys. Just a guess but it almost looks like it as it does get passed back to http.sys for the response. You could enable http logging to see if there is anything in that area causing the slowness.
Sue
June 16, 2018 at 5:28 pm
I'm curious... who is actually going to peruse a 4,000 row HTML document?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2018 at 3:55 am
Jeff Moden - Saturday, June 16, 2018 5:27 PMI'm curious... who is actually going to peruse a 4,000 row HTML document?
More likely the user is opening the web page, which loads the html rendered version, and then downloading the file in a different format (i.e. xlsx). Unfortunately, SSRS doesn't have an option to export a report until after it has been rendered in the web browser outside of a subscription.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
June 18, 2018 at 7:50 am
Thom A - Sunday, June 17, 2018 3:55 AMJeff Moden - Saturday, June 16, 2018 5:27 PMI'm curious... who is actually going to peruse a 4,000 row HTML document?More likely the user is opening the web page, which loads the html rendered version, and then downloading the file in a different format (i.e. xlsx). Unfortunately, SSRS doesn't have an option to export a report until after it has been rendered in the web browser outside of a subscription.
It's possible to export directly a report with ssrs directly without rendering it in browser but it's not the pupose here.
Why the user need a 4000 rows HTML document ? No idea, I'm quite sure there is no need so the paging is an acceptable solution.
But why a 4000 rows HTML document render in 20s in HTML4 and 10min in HTML5 ?
June 18, 2018 at 11:22 am
Julien Maillard - Monday, June 18, 2018 7:50 AMThom A - Sunday, June 17, 2018 3:55 AMJeff Moden - Saturday, June 16, 2018 5:27 PMI'm curious... who is actually going to peruse a 4,000 row HTML document?More likely the user is opening the web page, which loads the html rendered version, and then downloading the file in a different format (i.e. xlsx). Unfortunately, SSRS doesn't have an option to export a report until after it has been rendered in the web browser outside of a subscription.
It's possible to export directly a report with ssrs directly without rendering it in browser but it's not the pupose here.
Why the user need a 4000 rows HTML document ? No idea, I'm quite sure there is no need so the paging is an acceptable solution.
But why a 4000 rows HTML document render in 20s in HTML4 and 10min in HTML5 ?
Heh... probably because of the old adage of "Change is inevitable... change for the better is not". 😀
Oddly enough, if you do something like this in T-SQL, the report arrives as email almost before you can get your finger off the {f5} key.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply