0

I have an async lambda running on a DispatcherTimer to get data from a web API. My code is as follows:

_timelineSeekTimer = new DispatcherTimer();
_timelineSeekTimer.Interval = TimeSpan.FromMilliseconds(500);
_timelineSeekTimer.Tick += async (e, o) =>
{
    var sw = new Stopwatch();
    sw.Start();
    Console.WriteLine("Init: " + sw.ElapsedMilliseconds);

    // Get HttpResponseMessage from VADAAR API
    var response = await VadaarExtensions.CenPostAsync("/viewers/" + Viewer.GetName() + "/canvases/default/renderers/01/time", "GETPAYLOAD");
    Console.WriteLine("Response Time: " + sw.ElapsedMilliseconds);

    // Extract JSON string from response
    var responseBodyAsText = await response.Content.ReadAsStringAsync();

    // Extract time value from JSON with regex @TODO: Not use regex
    var parseJsonTime = Regex.Match(responseBodyAsText, @"(\d+)}").Groups[1].Value;
    ulong timeUs = ulong.Parse(parseJsonTime);
    TimelineSec = timeUs * 1e-6;

    Console.WriteLine("Current Seek Time: " + TimelineSec);
};

My problem is that the faster the timer runs, the function starts to fail. Here is a sample output of the function:

Init: 0
Response Time: 14
Current Seek Time: 0.543245

<snip>

Init: 0
Response Time: 18
Current Seek Time: 8.668584

Init: 0

Init: 0
Response Time: 887
Current Seek Time: 10.553811

<snip>

Init: 0
Response Time: 885
Current Seek Time: 18.67975

Init: 0

Init: 0
Response Time: 1760
Current Seek Time: 20.56805

When using the browser-based GUI for the API, the response time is somewhere between 15-30ms. What is the explanation for these failures, and why does the response time get worse with each one?

DeathTails
  • 468
  • 4
  • 12
  • Did you make sure that it's not the remote server becoming slower? – usr Feb 23 '16 at 16:02
  • @usr It's currently being run local. And when I use the browser GUI, the response time is still between 15-30ms as I would expect. – DeathTails Feb 23 '16 at 16:04
  • 2
    Use Fiddler to make sure that the response time was fast although your timing code shows slow numbers. – usr Feb 23 '16 at 16:07
  • @usr Haven't seen that before. I'll give and it a shot, and see what comes up. – DeathTails Feb 23 '16 at 16:08

1 Answers1

1

The response time you are measuring with the StopWatch is not enough. That are only the first-byte response headers. Afterwards you are reading the response itself, it takes some time more. Defining the Intervall smaller then full response + read time you cause the network flood with parallel and overlapping requests, so its gets slower and slower.

tenbits
  • 7,568
  • 5
  • 34
  • 53
  • That's probably it. Remote server is slow, measurement is broken. – usr Feb 23 '16 at 16:22
  • I had a timer in for reading the response as text, but it consistently took 0-1ms so I took that timer out. – DeathTails Feb 23 '16 at 16:23
  • @DeathTails 0-1 ms is not a constant, so you better include it in stopwatch measure. But anyway, even from your sample: we see you have the response times about 800ms, so you get already an overlapping request as 300 ms before, the timer fired again. So you have 2 options: make sure your timer is greater as request+read time, or you create some queue to ensure your new request is fired after the previous is ready. – tenbits Feb 23 '16 at 16:38