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

Qh3 performance benchmark example #63

Open
gmarzot opened this issue Mar 29, 2025 · 4 comments
Open

Qh3 performance benchmark example #63

gmarzot opened this issue Mar 29, 2025 · 4 comments

Comments

@gmarzot
Copy link

gmarzot commented Mar 29, 2025

This is a feature request but I imagine would also be useful as part of the project ci/cd process. To see if any changes help or hurt end to end performance.

@gmarzot
Copy link
Author

gmarzot commented Apr 8, 2025

I have been trying to push/pull higher bandwidth through qh3 .. I suspect I can speed things up with a custom reader but right now i am just processing quic_event_received and end up copying event data and buffered data more than would be ideal.. however this py-spy output seems to show the qh3 layer is consuming the most cpu ... this is single threaded on a Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz and the consuming side is almost at 100% cpu. I am running with 4 quic streams and only getting around 256Mbps over loopback. Much less than possible/expected.

Thank you for any thoughts or requests for additional data

Image

@gmarzot
Copy link
Author

gmarzot commented Apr 9, 2025

moqt/quic publisher profile

moqt/quic subscriber profile

this is py-spy speedscope capture for my publisher and subscriber

can be viewed here: https://speedscope.app

@Ousret
Copy link
Member

Ousret commented Apr 9, 2025

I'll see what I can do to improve the bottlenecks.

regards,

@gmarzot
Copy link
Author

gmarzot commented Apr 13, 2025

another observation is that when i run my publisher (primarily calling create_wt_stream() send_stream_data() transmit() ), the cpu use steadily increases over time. I have been looking for leaks with memray, but nothing obvious yet.. There is definitely something getting slower over time which makes me think some kind of leak or increasingly inefficient search(?)

Image
the RSS is creeping up ever so slowly - hard to imagine that is the cause of slowness

memray-flamegraph-pub_example.py.47978.html.txt (note: need to download and rename .html)

I wonder if I am not closing my streams cleanly?

                    session._quic.send_stream_data(stream_id, msg.data, end_stream=True)
                    session.transmit()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants