Added a Haskell server [in progress]

[bitemyapp]

I ran the client and server on me own machine, think it would unbound it a bit if they were separated like in your setup.

I got, uh, pretty good results.

This benchmark with Tsung is roughly what I expected in terms of results modulo hardware differences, which is why I wasn't that surprised when I saw the initial results.

Retracted numbers as I cannot reproduce with the unagi-chan variant.

So far it looks like a websockets implementation issue, but I'm not yet certain why this surfaced with unagi-chan and not Broadcast. Still digging in.

[bitemyapp]

For contrast, Rust on the same machine:

Golang:

C++:

[bitemyapp]

The Haskell server peaked at 1.28 gb of memory used based on the eyeball-htop method suggested.

[farnoy]

The response time spread seems minimal, have you tuned GC in any way to achieve this result? Weird not seeing pauses affect your 95th percentile.

[bitemyapp]

@farnoy I did nuh-zink. What you see (in the diff) is what you get. Just the ghc-options specified in the cabal file.

[tinco]

hi @bitemyapp, you might want to split the fix for clojure and the fix for cpp into separate PR's so hashrocket can more easily judge this one on its merit

[jmspiewak]

Doesn't Control.Concurrent.Broadcast drop messages (i.e. it's not really a channel)? I think unagi-chan would be better here.

[zyla]

It does indeed drop messages.

After adding received message counting to websocket-bench(https://github.com/zyla/websocket-shootout/commit/b4c7104e4bcf0377a55e899000159fdd3efcb6c6) and a minor fix in the haskell server (https://github.com/zyla/websocket-shootout/commit/0c329a6920aa2706e9141586d450cf13c28907e5), the results are:

clients:  1000  expected: 100000  rcvd:  1960  95per-rtt:  53ms  min-rtt:   1ms  median-rtt:  50ms  max-rtt:  79ms
clients:  2000  expected: 200000  rcvd:  3939  95per-rtt:  98ms  min-rtt:   2ms  median-rtt:  96ms  max-rtt:  99ms
clients:  3000  expected: 300000  rcvd:  5993  95per-rtt: 181ms  min-rtt:  39ms  median-rtt: 160ms  max-rtt: 207ms
clients:  4000  expected: 400000  rcvd:  7751  95per-rtt: 244ms  min-rtt:   2ms  median-rtt: 241ms  max-rtt: 245ms
clients:  5000  expected: 500000  rcvd:  9957  95per-rtt: 246ms  min-rtt:   2ms  median-rtt: 237ms  max-rtt: 252ms

Here expected is the number of broadcast messages we expect to receive, and rcvd is the how many actually arrived. These of course are supposed to be the same, and for other servers they are.

[bitemyapp]

@tinco it's not included, just a rebase with one too many steps back.

[bitemyapp]

Kicking around the unagi-chan variant @sgraf812 PR'd, definitely don't merge this for now, original version I wrote was not correct!

[tumdum]

@bitemyapp It's a shame you removed original PR comment - future readers will be lost.

[bitemyapp]

@tumdum well, people were getting nasty about it on Reddit, so I figured I'd amend it to shift focus to the retraction and what we were doing to fix it. I wasn't going to leave a (visually prominent) screenshot of erroneous results up because are apt to see the screenshot and ignore the text.

Currently I'm getting weird interactions between the client and server and trying to figure out what's going on.

[jackc]

Not sure if this is still in progress or how it relates to the other Haskell PR, but the websocket-bench tool now checks for too many or too few broadcasts.

[jackc]

There hasn't been any activity on this PR for a while, and we have a Haskell server merged now. So I'm going to close this PR. Feel free to reopen if there are any further developments.

[bitemyapp]

@jackc 👍