"Bruce L-C [MVP]" wrote:

> I highly recommend looking at the new controls with VS 2005. You can easily
> embed that and get everything. It comes with winform and webform controls.
>
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
>
> "Keith Rome" <KeithRome@discussions.microsoft.com> wrote in message
> news:7BEAA016-EAEA-4E8E-B0C0-38C582B04CE0@microsoft.com...
> >I figured it was pretty abnormal.
> >
> > Let me be a little more clear about where the performance is actually
> > suffering...
> >
> > The server-side rendering is not a problem. HTML renders just as fast (or
> > faster) than PDF or XLS. The only difference at that point is HTML output
> > data size being roughly 15 times that of PDF output, or more (I store the
> > rendered results in an intermediate database table, where it is very easy
> > to
> > calculate the blob sizes).
> >
> > The problem lies in the browser rendering. In other words, the page gets
> > all
> > the way back to the browser in only a few seconds... but then the browser
> > spends 10 minutes or more just trying to display the page. During this
> > pause,
> > the browser (not the server) peaks the CPU and consumes around 350M of
> > memory. It eventually shows the output and CPU drops back to zero after
> > the
> > 10 to 15 minute delay. Also, when I navigate away from the page displaying
> > the report, there is about a minute or so of delay while the browser again
> > peaks the CPU.
> >
> > My guess is that the HTML being sent to the browser is so bloated with
> > elements and inline styles that IE is suffering when attempting to parse
> > and
> > display it all - and suffering again when it must deallocate it later.
> >
> > Report Manager does not suffer like this - but then again Report Manager
> > allows for pagination of the report. I am not aware of a good way to
> > manually
> > retrieve individual pages from a rendered report (using the web
> > service)...
> > which would be necessary in order to enable pagination in the user
> > application.
> >
> > At this point I am leaning towards disabling the ability to render in HTML
> > (forcing PDF or XLS) in this application. Inline HTML was just such a nice
> > touch though - I would have preferred not having to discard it.
> >
> > --
> > Keith Rome
> > MCSD, MCAD, MCDBA
> >
> >
> > "Bruce L-C [MVP]" wrote:
> >
> >> This is very weird and the exact opposite of what is normally seen. PDF
> >> and
> >> Excel take on average 10 times longer to render than HTML and CSV. This
> >> is
> >> especially true the more data or the more complicated. HTML should just
> >> scream (speed wise).
> >>
> >> Trust me when I say, something is very very wrong with what you are
> >> seeing.
> >> First, what happens when viewing the report with Report Manager.
> >>
> >> If Report Manager is fast (which I suspect it will be faster than your
> >> PDF)
> >> then the issue is somewhere else.
> >>
> >>
> >> --
> >> Bruce Loehle-Conger
> >> MVP SQL Server Reporting Services
> >>
> >> "Keith Rome" <KeithRome@discussions.microsoft.com> wrote in message
> >> news:671301E4-7A23-4AA4-9296-BF34001F9A55@microsoft.com...
> >> > Looking a little deeper, when I render to HTML there is roughly 3M of
> >> > HTML
> >> > being generated. The same report using the same criteria renders a 76K
> >> > PDF. I
> >> > am guessing the bloat is due to SRS's love for tables and inline
> >> > styles?
> >> >
> >> > Should I just disable the ability to render to HTML, and force PDF or
> >> > Excel?
> >> > It sure was a nice touch being able to display reports as inline HTML
> >> > (I
> >> > use
> >> > the web service to render fragments into a div on a portal). I would
> >> > prefer
> >> > to not toss out the baby with the bath water...
> >> >
> >> > --
> >> > Keith Rome
> >> > MCSD, MCAD, MCDBA
> >> >
> >> >
> >> > "Keith Rome" wrote:
> >> >
> >> >> I have a RDL report, very very simple in nature. It is a basic listing
> >> >> report
> >> >> (uses a Grid, no filters or calculations in the report itself). The
> >> >> query
> >> >> is
> >> >> not complicated at all, sorting and filtering are applied in the query
> >> >> directly (no filters). Typical usage of the report brings back roughly
> >> >> 19
> >> >> pages of data.
> >> >>
> >> >> When executed to PDF or Excel formats, the performance is very
> >> >> reasonable...
> >> >> maybe 4 or 5 seconds total wait time. When rendering to HTML however,
> >> >> it
> >> >> is
> >> >> horribly slow. I have performed a SQL Profiler trace to look for
> >> >> anything
> >> >> abnormal - the issued queries look fine, and execute in under 4
> >> >> seconds.
> >> >>
> >> >> When running with HTML format for output, things look normal for 4 or
> >> >> 5
> >> >> seconds as the server processes, then the response comes back to the
> >> >> browser
> >> >> and it becomes unresponsive for up to 10 minutes. It winds up to 80%
> >> >> CPU
> >> >> utilization while memory usage leaps up beyond reason. It eventually
> >> >> responds
> >> >> again after a few minutes, and displays the report.
> >> >>
> >> >> I am guessing SRS is generating HTML that is causing a lot of
> >> >> crunching
> >> >> in
> >> >> the browser in order to display it. Has anyone here seen this before
> >> >> and
> >> >> have
> >> >> any ideas on how to deal with it?
> >> >>
> >> >> Again, this report is fairly vanilla (in my experience) - I am quite
> >> >> surprised to be having performance trouble with it - and I would have
> >> >> expected trouble from the PDF renderer long before HTML trouble...
> >> >>
> >> >> Thanks for your time.
> >> >>
> >> >> --
> >> >> Keith Rome
> >> >> MCSD, MCAD, MCDBA
> >>
> >>
> >>
>
>