Inconsistent performance?

[0XPW87]

Hello,

I have tried reqwest out, but I seem to be getting wildly inconsistent performances between runs. The response time seems to vary usually between ~360ms-1200ms (which by itself is a lot), occasionally [although rarely, idk, ~1/100?] reaching values as high as 11s (this is weird; I have tried multiple servers and networks).

There doesn't seem to be much of a difference whether or not I use the short call once, twice, or a client once/twice (ie to eliminate DNS lookups and whatever). Oftentimes, with the same request performed twice on the same client sequentially, the first would take ~500ms and the later ~900ms. Below is the rust code I used:

#[tokio::main]
async fn main() {
    // let c = reqwest::Client::new();
    let z = std::time::Instant::now();

    //short vs client
    reqwest::get("https://example.org").await.unwrap().text().await.unwrap();
    //c.get("https://example.org").await.unwrap().text().await.unwrap();
    dbg!(z.elapsed());

    //for double (client) requests
    //let z = std::time::Instant::now();
    //c.get("https://example.org").await.unwrap().text().await.unwrap();
    //dbg!(z.elapsed());
}

I can't seem to find an explanation for this. For reference, I performed the same test with JS/Bun, with this code:

let t = performance.now();
console.log((await (await fetch("https://example.org")).text()).toString())
console.log(performance.now() - t)

and I am getting pretty consistently 350 ± 10ms, with occasional spikes of ~850ms (~ 1/50).

I find this slightly concerning, and was wondering whether someone could shine a light on:

a) why the inconsistency
b) how come JS fetch is faster?
c) what I could do to get similar results to the JS/Bun example

Thank you!

[seanmonstar]

Hard to say, some thoughts:

• compiling with release?
• reusing a client not only pools connections, but only once needing to load TLS certs etc

Possibly other things. Generally reqwest is extremely fast, so could be network or other things.

[0XPW87]

Hi, thank you-

yes, thought of that- release didn't change much, and I am reusing the client- part of that is in the example, the commented lines.

For the network part, the JS code ran on the same machine almost immediately afterwards, with the results stated- the computer had a solid ethernet connection the whole time. I could understand the more extreme spikes being a network issue of some sorts, but the general deviations are harder to pin on the network, since the JS example does not suffer from them.

Is there anything I could do to try and track them down?

[0XPW87]

Hello,

I know it's been a while- I'd still like to get to the bottom of this, since I will probably be needing this in the near future. I ran some more tests in the style of what I already wrote, with similar results.

Do you have any recommendations, benchmarks or something I should try?
I will admit, networking isn't my strongest suite..

[wartab]

We do not have these types of issues.

Perhaps you could enable all Tracing logs (at Trace level), to at least narrow down what part of the request is taking so long?

Did you also encounter these issues by skipping DNS resolution entirely and connecting to the IP addresses directly and setting the host header yourself? What about 127.0.0.1? Do you ever have any issues then?