Best API for low latency

I have a small client application that does simple calculations. Now i want to make it report the results to my asp server. Other clients in the same wifi network should take the results and also work on those calculations. So they have to exchange their results as fast as possible. The rest api is too slow for that though. I thought that a gRPC stream would be more suitable for this Task. UDP maybe? Does a faster API even help even if i want exchange data without a direct ethernet connection?

why is a rest api too slow

It seems that my application spends more time reporting the results, than actually calculating

did you actually profile it ?
or it's more like a perception for now ?

For what purpose does this have to be super fast

The application should work on the traveling salesman problem, so in best case every calculation uses the results of the previous calcolation

Work on the salesman problem? As in use the best algorithm for the problem, or try to find a better algorithm?
Unless you have a university level supercomputer then the latter will be pointless I think

The different top algorithms for the problem are like 0.0001% apart in performance, and have been for years so it'll be hard to improve

1.) did you actually profile it ? or you're making assumption ?
2.) what's your SLA ?
3.) did you ran TCPDUMP on server side ?
4.) did you ran TCPDUMP client side ?
5.) did you reconciliate to see where's the latency is ?
6.) how does all these result prouve the issue is realy at L7 lvl of kestrel ?
7.) did you tried to force H2 ?
8.) did you tied without wifi ?

well i wont be able to create a better algorithm than anything that already exists, but thats not the point, im just trying things out

hello ?

1.) Yes
2.) No
3.) No
4.) No
5.) Yes
6.) ?
7.) No
8.) Yes

you can't do 5 without 3 and 4

sry pls give me some time i have to translate

¯\_(ツ)_/¯

i tried to measure it on client

6: if you can't have 3 4 and 5 you can't tell about L7 (http)

client means nothing

because there's the network infra

hence point 3 and 4

if you measure only client side you measure notion relatable

it can even be the client being slow

and not the server

it could be your network

makes sense

how did you profiled 1 ?

please tell me you never used DateTime.Now

if you used DateTime for anything in your computation you can throw your result

network, especially lan is supposed to be ~1ms or less

Stopwatch 😅

DateTime precision is ~16ms

stopwatch is "fine" but only if you make the full round

because you can't trust clock

which mean adding a stamp at each step

and measure deviation

Isn't there a github repo for benchmarks that could be helpful to determine the application code is not what's making it slow?
edit: found it - https://github.com/dotnet/BenchmarkDotNet

with possibly a pre-round of average to get the clock drift

I really think your issue is not the fact that it's a REST application

it's either the way you bind

or your network

or your computation

this is hard to bench network with that

Yea I meant he could use it to rule out his application code before he moves on to infra

sure

you will need to tell more or show your actual repo link if you want more help

If i start the client locally it's as fast as i expect it to be

well then it's not the REST part

try on LAN without WIFI

yes ill do that first. I thought that a different API could eventually resolve my problems somewhere else. But I can see now that i should start somwhere else.

maybe the way you expose/bind/parse the data is not helping

i also have to change the way i report my results

but if you're saying it's superfast on localhost

why would that be the code issue just by using wifi ?

currently my application stops calculating until it finished checking the results on the server

it's too abstract at this point

and thanks for those. Ill try checking all of these afterwards

changing the way i report it could make the network issue less relevant

there's A LOT of possible factor

what's important is you load the app is to make your you draw all the round about that each packet does

and when you make a measurment make sure to look at the graph

between what point and what point

and then accept that it's the sum of these

and you can be 100% sure the repartition is not uniform

so you need to either change measurmenet location

or make multiple measurement at once

and if you change something ... try to change at little at possible

* never use Timer class
* never use DateTime class

they are not precise AT ALL

* never use await task.delay or Thread.sleep (because they rely on a timer, and thus not precise)

use stuff like Bombardier or Benchmark.net if you need to time load

or make a precise timed loop using spingwait + stopwathc if you need precise cadence

using while(true){send} wihtout interval will simply DOS your network here or there and your mesurement will be invalid

aka: you might saturate some infra / buffer and you would only measure how bad is your infra when your infra is dying <== is it really relevant ?

Ok, thanks. There are quite a few thing i want to check before that.
Basically the only thing i know so far is that the entire thing is factor 10 slower if the client is running on a different machine than the server application. Ill adapt the measuring if the rougher issues are solved.

WIFI is fucking slow in general TBH