0

I have a APS.NET webapi which receives a request, performs a request to another API and returns the HttpResponse from that API back to the client (ie a proxy). Its using a heap of CPU, (much more than the internal API event though they are under the same load).

I did some profiling with ANTs and found that most of the time seems to be spent inside flushing the response stream which seems pretty weird.

The response is fairly simple and has a single double as its content, however the flush method seems to be using approx 60% of the cpu time.

Does anyone know what might be causing this CPU load or what I could do to investigate it?

If its helpful the code is approximately this:

private static HttpClient _client = new HttpClient();
public async Task<HttpResponseMessage> Stuff()
{
    return await _client.GetAsync("https://another.api/stuff");
}

enter image description here

undefined
  • 33,537
  • 22
  • 129
  • 198
  • A lot of `Stream` async flushing is currently not "truly" asynchronous and uses CPU bound tasks under the hood. Maybe you can switch to synchronous stream operations (at least synchronous flushing). I'm not certain, but it _might_ be the reason. – Sergey.quixoticaxis.Ivanov Feb 19 '17 at 20:01
  • I've experienced the same problem with disk IO operations. StreamWriters.FlushAsync was ten thousands times slower then synchronous version. – Sergey.quixoticaxis.Ivanov Feb 19 '17 at 20:03
  • @Sergey.quixoticaxis.Ivanov I don't think there should be a disk component at all. AFAIK it should just be reading the response stream from the inner request and writing it out to the open socket with the client. Perhaps its locking the CPU while its receiving data from the inner request? – undefined Feb 19 '17 at 21:47
  • Yeap, I understand. I meant that I had this problem when working with disk IO (not implying you do). But I suppose that CPU-heavy asynchronous implementation is there for most of the `Stream`s. – Sergey.quixoticaxis.Ivanov Feb 19 '17 at 22:19

0 Answers0