Dlaczego powinienem tworzyć asynchroniczne operacje WebAPI zamiast synchronizować operacje?

Mam następującą operację w utworzonym przeze mnie interfejsie API sieci Web:

// GET api/<controller>
[HttpGet]
[Route("pharmacies/{pharmacyId}/page/{page}/{filter?}")]
public CartTotalsDTO GetProductsWithHistory(Guid pharmacyId, int page, string filter = null ,[FromUri] bool refresh = false)
{
    return delegateHelper.GetProductsWithHistory(CustomerContext.Current.GetContactById(pharmacyId), refresh);
}

Wywołanie tej usługi sieciowej odbywa się za pośrednictwem wywołania Jquery Ajax w następujący sposób:

$.ajax({
      url: "/api/products/pharmacies/<%# Farmacia.PrimaryKeyId.Value.ToString() %>/page/" + vm.currentPage() + "/" + filter,
      type: "GET",
      dataType: "json",
      success: function (result) {
          vm.items([]);
          var data = result.Products;
          vm.totalUnits(result.TotalUnits);
      }          
  });

Widziałem kilku programistów, którzy implementują poprzednią operację w ten sposób:

// GET api/<controller>
[HttpGet]
[Route("pharmacies/{pharmacyId}/page/{page}/{filter?}")]
public async Task<CartTotalsDTO> GetProductsWithHistory(Guid pharmacyId, int page, string filter = null ,[FromUri] bool refresh = false)
{
    return await Task.Factory.StartNew(() => delegateHelper.GetProductsWithHistory(CustomerContext.Current.GetContactById(pharmacyId), refresh));
}

Muszę jednak powiedzieć, że GetProductsWithHistory () to dość długa operacja. Biorąc pod uwagę mój problem i kontekst, jakie korzyści przyniesie mi asynchroniczna operacja interfejsu webAPI?

W twoim konkretnym przykładzie operacja nie jest w ogóle asynchroniczna, więc to, co robisz, to asynchronizacja przez synchronizację. Po prostu zwalniasz jeden wątek i blokujesz inny. Nie ma powodu, ponieważ wszystkie wątki są wątkami puli wątków (w przeciwieństwie do aplikacji GUI).

W mojej dyskusji o „async over sync” zdecydowanie zasugerowałem, że jeśli masz interfejs API, który wewnętrznie jest implementowany synchronicznie, nie powinieneś ujawniać asynchronicznego odpowiednika, który po prostu otacza metodę synchroniczną Task.Run.

Od Czy należy uwidaczniać otoki synchroniczne dla metod asynchronicznych?

Jednak podczas wykonywania wywołań asyncinterfejsu WebAPI, w których występuje rzeczywista operacja asynchroniczna (zwykle we / wy) zamiast blokowania wątku, który siedzi i czeka na wynik, wątek wraca do puli wątków, dzięki czemu może wykonać inną operację. Oznacza to, że Twoja aplikacja może zrobić więcej przy mniejszych zasobach, a to poprawia skalowalność.

Jednym podejściem mogłoby być (z powodzeniem stosowałem to w aplikacjach klientów), aby usługa Windows uruchamiała długie operacje z wątkami roboczymi, a następnie robiła to w usługach IIS, aby zwolnić wątki do momentu zakończenia operacji blokowania: Uwaga, zakłada się, że wyniki są przechowywane w tabeli (wiersze identyfikowane przez jobId), a czystszy proces czyści je kilka godzin po użyciu.

Odpowiadając na pytanie: „Biorąc pod uwagę mój problem i kontekst, jakie korzyści przyniesie mi ustawienie asynchronicznej operacji interfejsu webAPI?” biorąc pod uwagę, że jest to „dość długa operacja”, myślę o wielu sekundach, a nie ms, takie podejście zwalnia wątki IIS. Oczywiście musisz również uruchomić usługę Windows, która sama pobiera zasoby, ale takie podejście może zapobiec zalewowi powolnych zapytań przed kradzieżą wątków z innych części systemu.

// GET api/<controller>
[HttpGet]
[Route("pharmacies/{pharmacyId}/page/{page}/{filter?}")]
public async Task<CartTotalsDTO> GetProductsWithHistory(Guid pharmacyId, int page, string filter = null ,[FromUri] bool refresh = false)
{
        var jobID = Guid.NewGuid().ToString()
        var job = new Job
        {
            Id = jobId,
            jobType = "GetProductsWithHistory",
            pharmacyId = pharmacyId,
            page = page,
            filter = filter,
            Created = DateTime.UtcNow,
            Started = null,
            Finished = null,
            User =  {{extract user id in the normal way}}
        };
        jobService.CreateJob(job);

        var timeout = 10*60*1000; //10 minutes
        Stopwatch sw = new Stopwatch();
        sw.Start();
        bool responseReceived = false;
        do
        {
            //wait for the windows service to process the job and build the results in the results table
            if (jobService.GetJob(jobId).Finished == null)
            {
                if (sw.ElapsedMilliseconds > timeout ) throw new TimeoutException();
                await Task.Delay(2000);
            }
            else
            {
                responseReceived = true;
            }
        } while (responseReceived == false);

    //this fetches the results from the temporary results table
    return jobService.GetProductsWithHistory(jobId);
}