title: Appropriate solution for long running computations in Azure App Service and .NET Core 3.1?
body: <p>What is an appropriate solution for long running computations in Azure App Service and .NET Core 3.1 in an application that has no need for a database and no IO to anything outside of this application ? It is a computation task.</p>
  <p>Specifically, the following is unreliable and needs a solution.</p>
  <pre><code>[Route(&quot;service&quot;)]
  [HttpPost]
  public Outbound Post(Inbound inbound)
  {
      Debug.Assert(inbound.Message.Equals(&quot;Hello server.&quot;));
      Outbound outbound = new Outbound();
      long Billion = 1000000000;
      for (long i = 0; i &lt; 33 * Billion; i++) // 230 seconds
          ;
      outbound.Message = String.Format(&quot;The server processed inbound object.&quot;);
      return outbound;
  }
  </code></pre>
  <p>This sometimes returns a null object to the <code>HttpClient</code> (not shown). A smaller workload will always succeed. For example 3 billion iterations always succeeds. A bigger number <s>would be nice</s> specifically 240 billion is a requirement.</p>
  <p>I think in the year 2020 a reasonable goal in Azure App Service with .NET Core might be to have a parent thread count to 240 billion with the help of 8 child threads so each child counts to 30 billion and the parent divides an 8 M byte inbound object into smaller objects inbound to each child. Each child receives a 1 M byte inbound and returns to the parent a 1 M byte outbound.  The parent re-assembles the result into a 8 M byte outbound.</p>
  <p>Obviously the elapsed time will be 12.5%, or 1/8, or one-eighth, of the time a single thread implementation would need. The time to cut-up and re-assemble objects is small compared to the computation time. I am assuming the time to transmit the objects is very small compared to the computation time so the 12.5% expectation is roughly accurate.</p>
  <p>If I can get 4 or 8 cores that would be good. If I can get threads that give me say 50% of the cycles of a core, then I would need may be 8 or 16 threads. If each thread gives me 33% of the cycles of a core then I would need 12 or 24 threads.</p>
  <p>I am considering the <code>BackgroundService</code> class but I am looking for confirmation that this is the correct approach. Microsoft says...</p>
  <pre><code>BackgroundService is a base class for implementing a long running IHostedService.
  </code></pre>
  <p>Obviously if something is long running it would be better to make it finish sooner by using multiple cores via <code>System.Threading</code> but this <a href="https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-3.1&amp;tabs=visual-studio" rel="noreferrer">documentation</a> seems to mention <code>System.Threading</code> only in the context of starting tasks via <code>System.Threading.Timer</code>. My example code shows there is no timer needed in my application. An HTTP POST will serve as the occasion to do work. Typically I would use <code>System.Threading.Thread</code> to instantiate multiple objects to use multiple cores. I find the absence of any mention of multiple cores to be a glaring omission in the context of a solution for work that takes a long time but may be there is some reason Azure App Service doesn't deal with this matter. Perhaps I am just not able to find it in tutorials and documentation.</p>
  <p>The initiation of the task is the illustrated HTTP POST controller. Suppose the longest job takes 10 minutes. The HTTP client (not shown) sets the timeout limit to 1000 seconds which is much more than 10 minutes (600 seconds) in order for there to be a margin of safety. <code>HttpClient.Timeout</code> is the relevant property. For the moment I am presuming the HTTP timeout is a real limit; rather than some sort of non-binding (fake limit) such that some other constraint results in the user waiting 9 minutes and receiving an error message. A real binding limit is a limit for which I can say &quot;but for this timeout it would have succeeded&quot;. If the HTTP timeout is not the real binding limit and there is something else constraining the system, I can adjust my HTTP controller to instead have three (3) POST methods. Thus POST1 would mean start a task with the inbound object. POST2 means tell me if it is finished. POST3 means give me the outbound object.</p>
  <p>What is an appropriate solution for long running computations in Azure App Service and .NET Core 3.1 in an application that has no need for a database and no IO to anything outside of this application ? It is a computation task.</p>