RDLC Performance Issues in .NET 4.5

I was recently tasked with investigating some performance issues related to RDLC reporting on a website. RDLC is the local implementation of SQL Server Reporting Services (SSRS) wherein report processing happens on an application server using in-memory data, and doesn’t require the use of an SSRS server. Reports can be embedded directly on a web page using the <asp:ReportViewer> control, which is quite nice.

RDLC support is built into .NET, and it’s an acceptable choice for smaller projects with simple reports. It’s also free, and that makes it an perfect choice for clients who don’t want to invest in a great tool. Commercial reporting tools get expensive, especially when you start looking into all the fun Business Intelligence, number-crunching options they provide.

The Problem

In this particular installation, the client requested a new report with a few more expressions and more levels of grouping than we had in previous reports. This new report also required more sub-total sections, many of which had aggregate calculations for Average and Sum. Unfortunately, the complexity of the report pushed its rendering time up into the tens of seconds on smaller reports, and lol-infinity amounts of time on larger ones. The entire report was unusable. I’m talking 10-15 minutes of processing for a 10-page report. It was that bad.

Searches online yielded very little information, until I eventually stumbled on a clue that Microsoft broke RDLC and failed to find the issue in regression tests:

The problem seems to be a degression that occured with the transition of the report viewer local mode to Net 4.0 running in the sandbox Domain (the Sandbox Domain is used by default in Net 4.0) … Expression Evaluation in Local Mode Unfortunately this problem was not caught in the Beta Testing.

More information can also be found here: Expression Evaluation in Local Mode

Solution Options

As it turns out, there are a few ways to fix the problem:

1. Force the use of legacy CAS security with the configuration option <trust legacyCasModel="true" level="Full"/>. I don’t even care what this does; it sounds like a terrible idea. Reverting to an older security model? No thank you. That said, I tried this, and it was no help. The use of dynamic variables in the project prevents using this legacy setting, and being an Umbraco project, we use them extensively in many of our Razor views.
2. Refactor the report. This may have helped somewhat, but the underlying issue would remain. Plus, refactoring the report felt like a giant hack. Given the next option, though, I seriously considered it.
3. Revert to .NET Framework 3.5. This is the part where you get to LOL and omgwtf, especially if you consider this is what I actually did … sort of.

The Solution

After much consideration, it made the most sense for me to split the reporting areas of the site out into another IIS Application running under .NET 3.5 (on a different subdomain), and add in some simple functionality to link between the two. It ended up being much easier than expected, and is thus far fully transparent to the client. No, it wasn’t fun, in case you’re getting jealous.

The good news is that the application is now able to process a 200-page report in roughly 12-15 seconds, and smaller reports of a few pages render in mere seconds.

Final Thoughts

Overall, RDLC is a decent technology that suffers merely from neglect. Report design is straightforward and relatively flexible. Displaying reports inline on a website is easy with the <asp:ReportViewer> tag, despite the viewer being a bit dated.

I really hope Microsoft will reinvest in RDLC for those of us who want a simple solution without selling family members to pay for it. It has the potential to be a great tool.