Great porject!

[goriunov]

This project looks great, ideally if you can make is without any dependencies (so all the code present in one repository) it would nice.

Also it might be that some people would be less interested in using the project as it is not reached the popularity required as yet, and it is not sure if this project has any vulnerabilities, stability, security issues etc...

Maybe a good approach would be to try and show that this code is safe/stable/secure somehow. Few general ways could be is to make it easy to follow, remove all dependencies (or only rely on the very popular/checked deps).

[lxzan]

Dependencies are essential at the moment, and the standard library is not powerful or performant enough.

[lxzan]

gws supports full permessage-deflate compression expansion, while the standard library does not support configurable sliding windows

[lxzan]

Although there are fewer dolthub/maphash stars, the dolthub organization can be trusted. If there are changes to the runtime in the future, relying on dolthub/maphash will make it easy to follow up.

[goriunov]

Really enjoyed reading through the source code of the project, I think it is well-structured and easy to follow.

We have moved over some of the services to observer the performance/stability so far look pretty good, the memory variation between min and max way better than on the gorilla, underline latency is about the same for our work load abit lower spikes on the unexpected throughput spikes, CPU got a bit better as well (still looking in to compression as looks like compression in some cases uses more CPU than i would expect)

I have noticed that you use the EventHandler structure with global struct needed to be created with call back functions such as OnOpen, OnClose etc... Was wondering if there was any particular reason for this design. TBH approach of gorilla feels more comfortable to work with at least in our scenario where the single connection is isolated, and we need to configure handlers post connection establishment but befor enabling read loop.

Abit more details we have our custom wrapper where after connection is established it would be passed in to the wrapper and then the whole system will work with that utility wrapper but with the EventHandler we need to manage the EventHandler integration with the wrapper and basically both of those have to track underline connection. (any way to simplify the migration from gorilla I have added a basic builder for event handler that kinda makes it similar to what we get from gorilla websocket, with few improvements)

Also just through I would drop in here as you looks like very interested in performance optimisations, may be will find something usefull in this project :)

https://github.com/talostrading/sonic

[lxzan]

Thanks for the compliment.

In a production environment, IOPS depends on your business load. For the same IOPS, gws has less memory and CPU overhead.
The compression operation is very CPU intensive, and it is recommended to disable compression for intranet communication. To compare the performance of compression, you should turn off context takeover (gorilla does not support this feature).

The main reason for using a global upgrader is to save memory, all connections share 32 compressors/decompressors, and secondly to simplify the management of the memory pool.

Performance wise, I will continue to improve #87

Strangely enough, in ReadMessage mode, the difference in IOPS between gorilla and gws under a 500B load is not that much, while 2KB and 8KB are very different.

[lxzan]

NextReader mode and without compression, gws is not much faster than gorilla, gws has the advantage of a lower memory footprint and more features.

[lxzan]

Enable Compression

➜  go-websocket-testing git:(dev) ✗ wsbench echo -c 1000 -n 200000 -f ./assets/github.json -u ws://localhost:8000/connect --latency --compress
10:02AM INF Percentage=49.68% Requests=99352
10:02AM INF Percentage=93.33% Requests=186651
10:02AM INF Percentage=100.00% Requests=200000
10:02AM INF Duration=2.339664827s IOPS=85482 P50=4ms P90=243ms P95=274ms P99=332ms
➜  go-websocket-testing git:(dev) ✗ wsbench echo -c 1000 -n 200000 -f ./assets/github.json -u ws://localhost:8001/connect --latency --compress
10:02AM INF Percentage=19.91% Requests=39821
10:02AM INF Percentage=39.29% Requests=78572
10:02AM INF Percentage=59.17% Requests=118341
10:02AM INF Percentage=78.93% Requests=157865
10:02AM INF Percentage=98.45% Requests=196900
10:02AM INF Percentage=100.00% Requests=200000
10:02AM INF Duration=5.215319344s IOPS=38348 P50=94ms P90=547ms P95=722ms P99=1037ms

[lxzan]