-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Poor datagram extension send performance #3766
Comments
Your analysis is correct. We haven't spent any effort optimizing the sending / receiving of datagrams yet. |
Would like to do some work on this if I can be pointed in the right direction. For the send queue it seems like we just need to increase the channel size to something reasonable. There's a lot of locking in the receive path and I'm thinking perhaps |
I'm also interested in this - it's not critical for my use case and I'm still trying to get some other things working, but good throughput is critical for me and in a perfect world it'd be slightly better to use datagrams as opposed to streams. @dongcarl have you been doing any work on it? |
Is this performance issue fully fixed now? |
I noticed that the sending rate of datagram frames is much lower than that of stream frames.
Example measurement with streams:
Example measurement with datagrams:
I narrowed the problem down to the send queue of capacity one and the blocking until the datagram is dequeued, i.e.,
sendQueue: make(chan *wire.DatagramFrame, 1)
andh.dequeued <- struct{}{}
indatagram_queue.go
.The text was updated successfully, but these errors were encountered: