Recommendations for developing a long-term resource-intensive web service

Question

I have a .NET function that does some complex calculations. Depending on the parameters that are transferred, the function:

• It takes from several minutes to several hours to start.
• In the calculation, 100% of one core is used.
• It takes from 100 MB to several GB of memory.
• Writes from a few MB to several GB of data to disk
• May throw an exception, including an OutOfMemoryException exception

The amount of data written to the disk can be accurately predicted from the parameterization of the function. There is no easy way to predict other resource requirements from function parameterization.

I need to open this function through a web service. This service should be:

• Resylant and elegantly report any problems during calculation
• The ability to handle concurrent requests, if there are sufficient resources to process the request without significant performance degradation and elegantly reject the request otherwise.

I intend to handle the long term if the initial request returns a status resource that can be queried to make progress. Upon completion of the calculation, this resource will provide the location of the output that the client can download (possibly via FTP).

I have a less clear understanding of how to deal better with other requirements. I am considering some kind of “calculation pool” that supports calculator instances and keeps track of which ones are currently in use, but I have not figured out the details.

Does anyone who has experience with such situations have any suggestions? While the solution can work in the Windows window, you can consider all the technology options.

Answer 1

I suggest dividing the application into two parts.

• Web service. This is the functionality:
  • Get a work item from a client;
  • Transfer this work to a server service that does the actual work;
  • Report progress and results;
• Backend service. This is the functionality:
  • Process web service requests;
  • Perform the actual calculation.

The reasons for this design: 1) it is relatively difficult to handle the workload in a hosted application (ASP.NET), because the server (IIS) will manage resources, while in a separate application you have more direct control;
2) the two-level design is more scalable - for example, later you can easily move the backend to another physical machine (or several machines).

The web service should be inactive - for example, after the request is accepted, the user will return some identifier and use this identifier to poll the service for the result.

The backend server should probably support a queue of processing requests and a set of workflows that process them. Workers must monitor available resources and ensure that they do not overload the machine (and, of course, gracefully handle all possible error conditions).

Answer 2

Although you can provide a web service interface, web services are usually not designed for such processes. What you might want to do is forward a request to a Windows service (on a dedicated machine) that can handle this. Windows services will not be recycled and you will have much more control over the process.

About the calculation pool: you can try to create a calculation queue (for example, a table in the database). That way, you can have multiple Windows services on dedicated computing machines. This can facilitate scaling.