可以使用按钮来运行cpu密集型代码，然后使用c＃和asp.net为Web应用程序显示结果吗？

Question

I am currently trying to create an application which has a homepage. On this homepage there is a button which is going to run CPU intensive code and then display the results. As I stated in the title the application is using ASP.NET and C# not Windows Forms which some other websites I have looked at seem to suggest.

I am relatively new to C# and have not attempted this in any other programming language. I also have no code to show as I don't really know how to progress this.

Answer 1

It can run CPU intensive code on the server, yes. Note that this will typically block your web application from sending a response in a reasonable amount of time and the web application could appear to be frozen.

What type of CPU intensive code did you have in mind? There are many ways to handle this scenario.

Answer 2

By "CPU intensive" I assume you mean it will take a long time for the process to complete? In a web application anything that takes more than a few moments should be done asynchronously. In the request/response model of HTTP it's best (for a number of reasons) to respond quickly to a client making a request.

In the case of a long-running process, by "asynchronous" I do not mean using AJAX, as that's still a request/response like any other.

By "asynchronous" what I mean in this case is that you want to have a separate server-side process which handles the CPU intensive task, and the web application does nothing more than queue the task for running and check the status of the task when people look for it. Then it can report the results of the task after it's done.

So a basic overview of the architecture would be something like this:

1. A user in the web application clicks a button to "start the task."
2. The web application inserts a record into a database table indicating that the task has been queued (maybe with a user ID of who queued it, a time stamp, anything else you'll need to know).
3. A separate scheduled application (console application or Windows Service, most likely) is perpetually running. (Either using a timer in an always-running Windows Service or scheduled to run over and over, such as every few minutes, as a console application.) This application checks the database table for new queued tasks.
4. When the application sees a task, it marks it as "started" in the database (so subsequent runs of the application don't try to run the same task in parallel) and starts running it.
5. The web application can see the status of the task in the database table and display it to users who request it, so users can see that it's still running.
6. When the task is completed, the task record in the database table is updated and the result is stored somewhere. (Depending on what the result is. Data? In the database. A report file of some sort? Save as a file somewhere. That's all up to you.)
7. The web application can see the status of the task as completed and any other information recorded, and users can request to view the output of the task.

The main thing to remember here is to break up the responsibilities into two applications . The web application is for the purpose of providing a user interface. A web application is not suited for long-running background tasks. So that responsibility is moved to a separate application which is better suited for that purpose. The two applications coordinate via a shared database.