Added a Haskell server [in progress] #14

Closed
wants to merge 14 commits into
from

Projects

None yet

9 participants

@bitemyapp
bitemyapp commented Sep 3, 2016 edited

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.

puredanger and others added some commits Sep 2, 2016
@puredanger @bitemyapp puredanger Enable direct linking in Clojure.
Direct linking is a compiler feature that is particularly useful for
AOT-compiled server programs. It removes some of the dynamicity of
Clojure (late dereferencing via vars) in favor of direct static calls
in the compiled code. This generally results in JVM bytecode that is
more amenable to JIT optimization by the JVM.
6214c6b
@bitemyapp bitemyapp Added Haskell
amended cabal file
ae77b09
@bitemyapp bitemyapp changed the title from Added a Haskell example to Added a Haskell, potentially handles more clients than C++ Sep 3, 2016
@bitemyapp

For contrast, Rust on the same machine:

screenshot from 2016-09-02 23-53-00

Golang:

screenshot from 2016-09-02 23-53-51

C++:

screenshot from 2016-09-02 23-56-27

@bitemyapp bitemyapp changed the title from Added a Haskell, potentially handles more clients than C++ to Added a Haskell server, potentially handles more clients than C++ Sep 3, 2016
@bitemyapp

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

@farnoy
farnoy commented Sep 3, 2016

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
tinco commented Sep 3, 2016

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
Contributor

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

@zyla zyla haskell: Follow websocket-bench protocol
`broadcast` goes to all clients, `broadcastResult` only back to the
sender.
0c329a6
@zyla
zyla commented Sep 3, 2016

It does indeed drop messages.

After adding received message counting to websocket-bench(zyla@b4c7104) and a minor fix in the haskell server (zyla@0c329a6), 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.

@sgraf812 sgraf812 referenced this pull request in bitemyapp/websocket-shootout Sep 3, 2016
Merged

Switched from Broadcast to unagi-chan, which doesn't drop messages #3

@bitemyapp bitemyapp Merge pull request #2 from zyla/haskell
haskell: Follow websocket-bench protocol
ea47d23
@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
tumdum commented Sep 3, 2016

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

@bitemyapp
bitemyapp commented Sep 3, 2016 edited

@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.

@bitemyapp bitemyapp changed the title from Added a Haskell server, potentially handles more clients than C++ to Added a Haskell server [in progress] Sep 3, 2016
@jackc
Member
jackc commented Sep 21, 2016

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
Member
jackc commented Oct 15, 2016

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.

@jackc jackc closed this Oct 15, 2016
@bitemyapp

@jackc ๐Ÿ‘

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment