Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(@libp2p/perf): Continously measure Performance on a Single Connection #2064

Closed
maschad opened this issue Sep 20, 2023 · 3 comments · Fixed by #2067
Closed

feat(@libp2p/perf): Continously measure Performance on a Single Connection #2064

maschad opened this issue Sep 20, 2023 · 3 comments · Fixed by #2067
Assignees
Labels
kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up topic/perf Performance

Comments

@maschad
Copy link
Member

maschad commented Sep 20, 2023

The motivation for the larger effort is documented in libp2p/test-plans#261.

Instead of downloading an arbitrary amount of MB multiple times, each on a new connection, establish a single connection and continuously measure the throughput for a fixed duration (60s by default). Perf stdout output would be refactored as such :

              interface Data {
                type: "intermediary" | "final";
                timeSeconds: number;
                uploadBytes: number;
                downloadBytes: number;
              }

where every second the client must print the current progress to stdout. See example below. Note the type: "intermediary".

               {
                 "type": "intermediary",
                 "timeSeconds": 1.004957645,
                 "uploadBytes": 73039872,
                 "downloadBytes": 0
               }

Before terminating, the client must print a final summary. See example below. Note the type: "final". Also note that the measurement includes the time to (1) establish the connection, (2) upload the bytes and (3) download the bytes.

               {
                 "type": "final",
                 "timeSeconds": 60.127230659,
                 "uploadBytes": 4382392320,
                 "downloadBytes": 0
               }
@maschad maschad added the need/triage Needs initial labeling and prioritization label Sep 20, 2023
@maschad maschad self-assigned this Sep 20, 2023
@maschad maschad added P1 High: Likely tackled by core team if no one steps up need/triage Needs initial labeling and prioritization topic/perf Performance kind/enhancement A net-new feature or improvement to an existing feature and removed need/triage Needs initial labeling and prioritization labels Sep 20, 2023
@maschad maschad changed the title Feat(@libp2p/perf): Continously measure Performance on a Single Connection feat(@libp2p/perf): Continously measure Performance on a Single Connection Sep 20, 2023
@mxinden
Copy link
Member

mxinden commented Sep 21, 2023

Thank you @maschad for the help here!

Instead of downloading x MB multiple times, each on a new connection, establish a single connection and continuously measure the throughput for a fixed duration (60s by default).

Just to avoid confusion, from the perspective of the js-libp2p perf binary, it is still a single connection and a single stream throughout its process lifetime.

@achingbrain
Copy link
Member

establish a single connection and continuously measure the throughput for a fixed duration (60s by default)

Just to be clear here, that is not what #2067 does. It transfers a fixed amount of data and once a second (give or take) it logs how much data was transferred during the previous interval.

achingbrain added a commit that referenced this issue Nov 7, 2023
Measures upload/download speed separately and also over time rather than in total.

Closes #2064

BREAKING CHANGE:  `measurePerformance` now returns an async generator that yields `PerfOutput`s and no longer accepts the `startTime` parameter

---------

Co-authored-by: Alex Potsides <[email protected]>
@mxinden
Copy link
Member

mxinden commented Nov 8, 2023

establish a single connection and continuously measure the throughput for a fixed duration (60s by default)

Just to be clear here, that is not what #2067 does. It transfers a fixed amount of data and once a second (give or take) it logs how much data was transferred during the previous interval.

The 60 seconds are enforced by the runner. Detail being that it is actually 20s, not 60s.

maschad added a commit to maschad/js-libp2p that referenced this issue Nov 10, 2023
Measures upload/download speed separately and also over time rather than in total.

Closes libp2p#2064

BREAKING CHANGE:  `measurePerformance` now returns an async generator that yields `PerfOutput`s and no longer accepts the `startTime` parameter

---------

Co-authored-by: Alex Potsides <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up topic/perf Performance
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants