high latency on 5.0-beta.1+15775e6

[MrFoxPro]

Describe the bug Latency is 3 times higher on 5-beta compared to 4+

edgedb-server [4.2]

Reqs/sec       565.77     179.53     993.94
Latency      220.20ms   164.53ms      2.86s
HTTP codes:
  1xx - 0, 2xx - 17083, 3xx - 0, 4xx - 0, 5xx - 0
  others - 0
Throughput:    14.50MB/s

edgedb-server [4.6]

Reqs/sec       590.69     178.51    1041.10
Latency      210.90ms   145.51ms      2.86s
HTTP codes:
  1xx - 0, 2xx - 17832, 3xx - 0, 4xx - 0, 5xx - 0
  others - 0
Throughput:    15.14MB/s

edgedb-server [5-beta]

Reqs/sec       201.97     118.78     595.80
Latency      615.08ms   356.76ms      3.57s
HTTP codes:
  1xx - 0, 2xx - 6155, 3xx - 0, 4xx - 0, 5xx - 0
  others - 0
Throughput:     5.16MB/s

• OS:
• EdgeDB version: 5.0-beta.1+15775e6
• EdgeDB CLI version: 4.1.0+03ae624
• Rust compiler version: 1.78.0-nightly
• Cargo version: 1.78.0-nightly
• EdgeDB Rust versions: master

[msullivan]

It seems like probably this should be a report against edgedb itself, not against the rust bindings?

Could you share a little more information on what your workload is here? These are HTTP requests? Against what endpoints? Do you have a test program you can share?

[MrFoxPro]

It seems like probably this should be a report against edgedb itself, not against the rust bindings?

Could you share a little more information on what your workload is here? These are HTTP requests? Against what endpoints?

I mean I'm not sure if it's exactly edgedb-server issue cause I tried to compare against NodeJS, but I wasn't able to receive informative/stable results from NodeJS version.

Yes, there are http requests (axum, tokio flavor = "multi_thread", profile release, lto, codegen-units = 1)

handler code

```rust #[derive(Deserialize)] struct GetUserQuery { nickname: Option, q: Option, } async fn get_user( State(ctx): State, Query(query): Query, user: shapes::MeUser, ) -> Result { if query.nickname.is_some() && query.q.is_some() { return Err(anyhow!("Only nickname or q can be specified at once").into()); } let get_user_query = format!( r#" with me_num := $0, q := $1, nickname := $2, users := ( select User filter (.can_be_visible or .num = me_num) and (.nickname = nickname) ?? true and ((q ilike "%" ++ .nickname ++ "%") ?? true or (q ilike "%" ++ .name ++ "%") ?? true) ) if (exists q or exists nickname) else (select User filter .can_be_visible and .num != me_num), deals := (select DealBase filter .owner in users), projects := (select Project filter exists (users intersect .participants)), select {{ multi users := users {{ {USER_SHAPE} }}, multi deals := deals {{ {MIN_DEAL_SHAPE} }}, multi tags := distinct (deals.tags union projects.tags union users.interests) {{ {TAG_SHAPE} }}, multi projects := projects {{ {MIN_PROJECT_SHAPE} }}, }} "#, USER_SHAPE = shapes::User::shape(), MIN_DEAL_SHAPE = shapes::MinDeal::shape(), TAG_SHAPE = shapes::Tag::shape(), MIN_PROJECT_SHAPE = shapes::MinProject::shape() ); let result = ctx .edb .query_required_single_json(&get_user_query, &(user.num, query.q, query.nickname)) .await?; return Ok(EdgedbJson(result)); } ``` Discord conversation: https://discord.com/channels/841451783728529451/1215922776595234927/1217908275253612627

[msullivan]

This seems like edgedb binary protocol, not http?

[msullivan]

Oh, the HTTP latencies are for your app

[MrFoxPro]

Oh, the HTTP latencies are for your app

yep

[MrFoxPro]

First column in table is Avg, second is Stdev, third is Max

[msullivan]

Just for record keeping, the latency increases were for PARSE messages sent from clients. The rust client does not properly cache queries to avoid extra PARSE round trips, so this did appear more using rust than using other bindings.

The issue was present in b1 and was related to how the new persistent cache operated, but major changes in the persistent cache mechanism meant the issue had been already fixed, and should be fixed in the newly released b2