Comments (13)
kenshaw
commented on May 18, 2024
I would greatly appreciate if this could be implemented, as we're benchmarking the different websocket implementations for use with the chromedp package. Unfortunately, I can't fix Chrome's implementation, so without this ability, it excludes evaluating this package. I understand the issue with the frame, but I haven't dug into this package's implementation. Would be glad to implement it, if given guidance. Thanks in advance!
from websocket.
nhooyr
commented on May 18, 2024
If you want pure performance, you definitely want to go with gobwas/ws, this library will not beat it.
I do not want to compromise this library's API early on without knowing how widespread this issue is or using benchmarks to see the speed improvement.
You can use the https://github.com/nhooyr/websocket/tree/exp-single branch if you still want to use it.
from websocket.
nhooyr
commented on May 18, 2024
In terms of performance, seems to be decently faster but will analyze if its worth it later.
+ go test --vet=off '--run=^$' -bench=. -cpuprofile=profs/cpu -memprofile=profs/mem -blockprofile=profs/block -mutexprofile=profs/mutex .
goos: linux
goarch: amd64
pkg: nhooyr.io/websocket
BenchmarkConn/stream/32-4 20000 64684 ns/op 0.49 MB/s
BenchmarkConn/stream/128-4 20000 70596 ns/op 1.81 MB/s
BenchmarkConn/stream/512-4 20000 68876 ns/op 7.43 MB/s
BenchmarkConn/stream/1024-4 20000 72584 ns/op 14.11 MB/s
BenchmarkConn/stream/4096-4 10000 107517 ns/op 38.10 MB/s
BenchmarkConn/stream/16384-4 10000 110108 ns/op 148.80 MB/s
BenchmarkConn/stream/65536-4 10000 196606 ns/op 333.34 MB/s
BenchmarkConn/stream/131072-4 5000 300750 ns/op 435.82 MB/s
BenchmarkConn/buffered/32-4 10000 114083 ns/op 0.28 MB/s
BenchmarkConn/buffered/128-4 20000 94734 ns/op 1.35 MB/s
BenchmarkConn/buffered/512-4 10000 117539 ns/op 4.36 MB/s
BenchmarkConn/buffered/1024-4 20000 97250 ns/op 10.53 MB/s
BenchmarkConn/buffered/4096-4 10000 109905 ns/op 37.27 MB/s
BenchmarkConn/buffered/16384-4 10000 125022 ns/op 131.05 MB/s
BenchmarkConn/buffered/65536-4 10000 163505 ns/op 400.82 MB/s
BenchmarkConn/buffered/131072-4 10000 213125 ns/op 615.00 MB/s
PASS
ok nhooyr.io/websocket 28.581s
from websocket.
nhooyr
commented on May 18, 2024
It's very confusing how at 4096 bytes, the buffered implementation is actually several thousand nanoseconds slower than the stream.
from websocket.
nhooyr
commented on May 18, 2024
Was just my MacBook CPU throttling lol.
Here are the results on a GCP VM:
nhooyr@anmol:~/go/src/nhooyr.io/websocket$ go test -bench=. -run=xxx
+ go test -bench=. -run=xxx
go: downloading github.com/google/go-cmp v0.2.0
go: downloading golang.org/x/time v0.0.0-20190308202827-9d24e82272b4
go: extracting github.com/google/go-cmp v0.2.0
go: extracting golang.org/x/time v0.0.0-20190308202827-9d24e82272b4
goos: linux
goarch: amd64
pkg: nhooyr.io/websocket
BenchmarkConn/buffered/32-2 100000 22014 ns/op 1.45 MB/s
BenchmarkConn/buffered/128-2 100000 22281 ns/op 5.74 MB/s
BenchmarkConn/buffered/512-2 100000 22602 ns/op 22.65 MB/s
BenchmarkConn/buffered/1024-2 100000 22659 ns/op 45.19 MB/s
BenchmarkConn/buffered/4096-2 30000 45452 ns/op 90.12 MB/s
BenchmarkConn/buffered/16384-2 30000 51056 ns/op 320.90 MB/s
BenchmarkConn/buffered/65536-2 20000 81324 ns/op 805.86 MB/s
BenchmarkConn/buffered/131072-2 20000 94991 ns/op 1379.82 MB/s
BenchmarkConn/stream/32-2 50000 36525 ns/op 0.88 MB/s
BenchmarkConn/stream/128-2 50000 37903 ns/op 3.38 MB/s
BenchmarkConn/stream/512-2 50000 35850 ns/op 14.28 MB/s
BenchmarkConn/stream/1024-2 50000 36173 ns/op 28.31 MB/s
BenchmarkConn/stream/4096-2 30000 48555 ns/op 84.36 MB/s
BenchmarkConn/stream/16384-2 20000 62526 ns/op 262.03 MB/s
BenchmarkConn/stream/65536-2 10000 102465 ns/op 639.59 MB/s
BenchmarkConn/stream/131072-2 10000 169573 ns/op 772.95 MB/s
PASS
ok nhooyr.io/websocket 34.457sfrom websocket.
nhooyr
commented on May 18, 2024
Given the significant difference for even 32 byte messages, at 65%, I think it makes sense to offer this API. Will expose it tomorrow.
from websocket.
nhooyr
commented on May 18, 2024
I am confused as to why though, there shouldn't be such a huge difference at such a small byte size 🤔
from websocket.
nhooyr
commented on May 18, 2024
Ok my benchmarks sucked. Here are better ones:
nhooyr@anmol:~/websocket$ go test -bench=BenchmarkConn -run=xxx
goos: linux
goarch: amd64
pkg: nhooyr.io/websocket
BenchmarkConn/buffered/32-2 300000 7823 ns/op 4.09 MB/s 64 B/op 3 allocs/op
BenchmarkConn/buffered/128-2 200000 8323 ns/op 15.38 MB/s 64 B/op 3 allocs/op
BenchmarkConn/buffered/512-2 200000 8339 ns/op 61.39 MB/s 64 B/op 3 allocs/op
BenchmarkConn/buffered/1024-2 200000 10306 ns/op 99.35 MB/s 64 B/op 3 allocs/op
BenchmarkConn/buffered/4096-2 100000 16132 ns/op 253.89 MB/s 64 B/op 3 allocs/op
BenchmarkConn/buffered/16384-2 100000 18691 ns/op 876.55 MB/s 64 B/op 2 allocs/op
BenchmarkConn/buffered/65536-2 20000 64167 ns/op 1021.32 MB/s 64 B/op 3 allocs/op
BenchmarkConn/buffered/131072-2 10000 126063 ns/op 1039.73 MB/s 64 B/op 3 allocs/op
BenchmarkConn/stream/32-2 200000 9874 ns/op 3.24 MB/s 128 B/op 6 allocs/op
BenchmarkConn/stream/128-2 200000 10530 ns/op 12.16 MB/s 128 B/op 6 allocs/op
BenchmarkConn/stream/512-2 100000 11944 ns/op 42.86 MB/s 128 B/op 6 allocs/op
BenchmarkConn/stream/1024-2 200000 12139 ns/op 84.36 MB/s 128 B/op 6 allocs/op
BenchmarkConn/stream/4096-2 100000 18846 ns/op 217.34 MB/s 128 B/op 6 allocs/op
BenchmarkConn/stream/16384-2 50000 23377 ns/op 700.84 MB/s 128 B/op 6 allocs/op
BenchmarkConn/stream/65536-2 20000 66540 ns/op 984.90 MB/s 128 B/op 5 allocs/op
BenchmarkConn/stream/131072-2 10000 129499 ns/op 1012.15 MB/s 128 B/op 6 allocs/op
PASS
ok nhooyr.io/websocket 30.153s
So looks like at larger message sizes the difference is negligible but at smaller sizes, its very significant because each Writer/Reader call has to allocate the reader/writer because they're being put inside an interface value. Thats why the stream is allocating so much more every op.
Its still not a large enough difference to warrant this coming in for performance reasons. 2000 nanoseconds isn't that much. The allocation overhead might matter but I'd like to wait to see other people's thoughts.
from websocket.
nhooyr
commented on May 18, 2024
I've also updated https://github.com/nhooyr/websocket/tree/exp-single
from websocket.
kenshaw
commented on May 18, 2024
@nhooyr cool, appreciate the effort, even if it's not something you plan on putting in the public API! We'll benchmark internally with chromedp and see how it works against the gorilla and gobwas implementations.
from websocket.
nhooyr
commented on May 18, 2024
I've decided against bringing this into the library. It's an unfortunate situation with chrome but I believe it's an outlier. For almost every single language, there is a robust WebSocket library available. See https://github.com/facundofarias/awesome-websockets or https://github.com/crossbario/autobahn-testsuite#users
A cursory google search of websocket fragmentation not supported only brings up chrome.
So for now, I would recommend you use gorilla or gobwas.
If someone else runs into another stack in the wild that also does not support fragmentation or has issues with the performance, I'll reconsider this.
from websocket.
nhooyr
commented on May 18, 2024
Argh, so I thought about this some more and I think its a good idea to include a Write and Read method anyway, not because of chrome but to reduce ceremony when using the library with a protocol that's not JSON/Protobufs.
If you're just experimenting, it's frustrating to have to create a writer or a reader to just write or read a simple msg.
The API is very minimal regardless so I think the trade off for the convenience is worth it as the godoc still reads well.
from websocket.
kenshaw
commented on May 18, 2024
OK.
from websocket.
Related Issues (20)
- Document how to have read timeout be larger than idle timeout HOT 3
- all goroutines are dead asleep - deadlock! wasm docs HOT 8
- Deadlocks due to CloseRead HOT 6
- Can't activate CORS for examples /chat/ HOT 2
- Reader() can only read one message, but Read() can read all messages HOT 5
- Error: panic: unaligned 64-bit atomic operation on arm32-bit while establishing websocket connection HOT 2
- Invalid readme example HOT 3
- Goroutine spike when closing connections in v1.8.10 (regression) HOT 3
- Transmit only single frame in Write when compression enabled too HOT 6
- Data race on `Conn.closeErr` HOT 3
- websocket.Conn.CloseNow() panics in WaitGroup.Wait HOT 2
- failed to get reader: use of closed network connection HOT 3
- Inline part of the full examples HOT 7
- Add custom ping message option to Ping function HOT 1
- failed to WebSocket dial: response body is not a io.ReadWriteCloser: io.nopCloserWriterTo HOT 1
- unsupported permessage-deflate parameter: "client_max_window_bits=15" from client HOT 8
- Update docs and mention explicit close required change in v1.8.11 HOT 16
- panic: sync: WaitGroup is reused before previous Wait has returned HOT 1
- Return net.ErrClosed from Read methods when connection is closed by us HOT 6
- failed: Close received after close HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from websocket.