search

eclipse-zenoh / zenoh

zenoh unifies data in motion, data in-use, data at rest and computations. It carefully blends traditional pub/sub with geo-distributed storages, queries and computations, while retaining a level of time and space efficiency that is well beyond any of the mainstream stacks.
https://zenoh.io
Other
1.5k stars 160 forks source link

[Bug] Session object instantiation is very slow #460

Open yellowhatter opened 1 year ago

yellowhatter commented 1 year ago

Describe the bug

It takes ~10 seconds to create 10 Sessions sequentially. It is too much, especially for some tests.

To reproduce

Create 10 Sessions sequentially with async or sync API.

System info

Mallets commented 1 year ago

Can you please provide a code snippet on how you create the session?

yellowhatter commented 1 year ago

Here is a test.

#[test]
fn session_perf() {
    let many_sessions: Vec<Session> = (0..10).map(|_| zenoh::open(zenoh::config::peer()).res_sync().unwrap() ).collect();
    assert!(many_sessions.len() == 10);
}

It takes 8 seconds to run it on my machine. res_async() API shows the same performance.

Mallets commented 1 year ago

Thanks!

@OlivierHecart: could the initial delay be related to scouting?

OlivierHecart commented 1 year ago

What we have today are:

  1. A configurable scouting_delay (default: 200ms) which goal is to make sure we discovered local peers before starting operating.
  2. A build-time configurable API_OPEN_SESSION_DELAY (default: 500ms) which goal is to make sure we discovered remote subscribers and queryables before applying writer side filtering.

Those delays add up to 7 seconds for 10 sessions.

The new interest protocol should allow to remove the API_OPEN_SESSION_DELAY. Still the scouting_delay should remain in peer mode.

yellowhatter commented 1 year ago

What about pre-initializing discovery data from already existing sessions when creating a new one? - if this would be possible, we could also avoid awaiting for scouting_delay.

Mallets commented 1 year ago

What about pre-initializing discovery data from already existing sessions when creating a new one? - if this would be possible, we could also avoid awaiting for scouting_delay.

I believe that creating so many sessions is useful mainly for testing purpose, I wouldn't expect the user to create that many. Generally, the user will interact with only one Zenoh session. In case of having different session, I'm expecting the users to do so by using different configurations for each session. If that's the case, then mutualizing discovery data can be very tricky. Are the different sessions discovering the same thing? Is it really the same system?

Long story short, if the scouting_delay is not acceptable in testing, why not avoiding scouting and setting the endpoints manually? Like here? Would that be an option?