search

Matheus28 / ws28

C++17 WebSocket server library (uses libuv)
MIT License
66 stars 10 forks source link

Better callback naming & benchmarks #1

Closed szmarczak closed 6 years ago

szmarczak commented 6 years ago
  1. Aren't these names... a bit weird? Here's my suggestion:

SetClientConnectedCallback: onConnection SetClientDisconnectedCallback: onDisconnection SetClientDataCallback: onData SetHTTPCallback: onHTTP

or more like JavaScript WebSocket - onOpen, onClose, onMessage...

  1. This lib seems to be very lightweight. How does this compare to uWS?
Matheus28 commented 6 years ago

  1. PascalCase is life. You'll only need to use these functions once per application, a bit more typing is fine.

  2. It should probably be around the same speed, I don't have time to test, but there are a few areas in which it could be made a bit faster.

Matheus28 commented 6 years ago

I tested performance a bit using uWS's benchmark programs in a not very scientific way, and throughput looks about 1/3 as fast as uWS. Plenty of room for improvement.

Matheus28 commented 6 years ago

I implemented corking, and it seems to be at about the same level of performance as uWS now, in their benchmarks. I didn't test for very long so there's definitely some noise in the results.

szmarczak commented 6 years ago
  1. PascalCase is life. You'll only need to use these functions once per application, a bit more typing is fine.

Can't argue with that. Different people have different likes :P

I implemented corking, and it seems to be at about the same level of performance as uWS now, in their benchmarks. I didn't test for very long so there's definitely some noise in the results.

Sounds awesome!

  1. Will it support reading HTTP POST data?
  2. Why did you downgrade to C++14?

I've played with this lib a bit, I love it!

Matheus28 commented 6 years ago

Also, I won't be optimizing further for uWebSockets benchmarks. Their benchmarks don't really test what I use websockets for. For example, corking/uncorking during the parsing of packets helps a lot in their echo benchmark (3x performance), but not nearly that much in my (and possible other) applications (since I don't usually send replies inside the callback for OnClientData).

I think a more realistic benchmark would be opening 10k connections and the server would have to send packets with random data with length 40~500 bytes as fast as it can to each connection (not the same random data to all connections).

  1. It's not too hard to implement (as in, probably <10 lines), but I don't use anything but GET requests on those websocket servers, so whoever wants it can make a pull request if they need it now.

  2. This doesn't really affect library consumers very much. C++17 isn't very well supported on Windows and older versions of other OSes.

szmarczak commented 6 years ago

I won't be optimizing further for uWebSockets benchmarks.

I do async jobs too :)

I think a more realistic benchmark would be opening 10k connections and the server would have to send packets with random data with length 40~500 bytes as fast as it can to each connection (not the same random data to all connections).

Agreed.

  1. [...] whoever wants it can make a pull request if they need it now.

Ok, will do! 😃

  1. [...] C++17 isn't very well supported on Windows and older versions of other OSes.

Oh, that's sad. Who stores servers on Windows nowadays? :o