Separate C# Project for Reporting - Best Practice?

Question

I have a few reports in an MVC C# Web project and they work fine. But I noticed that on the live site people tend to select large report date ranges and other search criteria which would return a fairly large data set.

As the whole site is on one IIS site in one project, this causes the rest of the site to hang until the report has finished execution.

I'm just wondering whats the best practice to handle this scenario?

Is it to move the reports to their own project with their own IIS site and somehow point to it from my main site?

Is it to make the reports async?

I could use view/stored procedures but I wanted to stay away from them.

I had a similar situation when using RDLC reports with Report View in ASP.NET web form pages - setting the session to readonly helped resolve the issue - https://stackoverflow.com/a/33311623/1910735 — Dawood Awan, Jan 13 '18 at 20:04
No reporting tools, its just C# with Linq, no reporting tools. — Bad Dub, Jan 13 '18 at 20:05
then I suggest you write Stored Procedures/Views, so they execute on the database and return a Dataset - and use async on the back-end — Dawood Awan, Jan 13 '18 at 20:07

score 2 · Accepted Answer · answered Jan 13 '18 at 19:37

Generating the report should not make the website unresponsive. The IIS is able to handle multiple requests at the same time, so only the request waiting for the report will be blocked/waiting -- any new request to the site should work fine as long as the website still has available requests. I think the default is 12 concurrent requests, and if all requests are taken, further requests will be queued.

It is good pracitce to use async and await for blocking/long-running processes. Doing so will "release" request while executing, so the IIS can serve another request until the process is finished.

Separate C# Project for Reporting - Best Practice?

1 Answers1