Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upAdded a Haskell server [in progress] #14
Conversation
puredanger
and others
added some commits
Sep 2, 2016
bitemyapp
changed the title from
Added a Haskell example
to
Added a Haskell, potentially handles more clients than C++
Sep 3, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bitemyapp
commented
Sep 3, 2016
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
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bitemyapp
Sep 3, 2016
The Haskell server peaked at 1.28 gb of memory used based on the eyeball-htop method suggested.
bitemyapp
commented
Sep 3, 2016
|
The Haskell server peaked at 1.28 gb of memory used based on the eyeball-htop method suggested. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
farnoy
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.
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bitemyapp
Sep 3, 2016
@farnoy I did nuh-zink. What you see (in the diff) is what you get. Just the ghc-options specified in the cabal file.
bitemyapp
commented
Sep 3, 2016
|
@farnoy I did nuh-zink. What you see (in the diff) is what you get. Just the |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tinco
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
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 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jmspiewak
Sep 3, 2016
Contributor
Doesn't Control.Concurrent.Broadcast drop messages (i.e. it's not really a channel)? I think unagi-chan would be better here.
|
Doesn't Control.Concurrent.Broadcast drop messages (i.e. it's not really a channel)? I think unagi-chan would be better here. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
zyla
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.
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:
Here |
sgraf812
referenced this pull request
Sep 3, 2016
Merged
Switched from Broadcast to unagi-chan, which doesn't drop messages #3
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bitemyapp
commented
Sep 3, 2016
|
@tinco it's not included, just a rebase with one too many steps back. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bitemyapp
Sep 3, 2016
Kicking around the unagi-chan variant @sgraf812 PR'd, definitely don't merge this for now, original version I wrote was not correct!
bitemyapp
commented
Sep 3, 2016
|
Kicking around the unagi-chan variant @sgraf812 PR'd, definitely don't merge this for now, original version I wrote was not correct! |
bitemyapp
added some commits
Sep 3, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tumdum
Sep 3, 2016
@bitemyapp It's a shame you removed original PR comment - future readers will be lost.
tumdum
commented
Sep 3, 2016
|
@bitemyapp It's a shame you removed original PR comment - future readers will be lost. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bitemyapp
Sep 3, 2016
@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
commented
Sep 3, 2016
•
|
@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
changed the title from
Added a Haskell server, potentially handles more clients than C++
to
Added a Haskell server [in progress]
Sep 3, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jackc
Sep 21, 2016
Contributor
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.
|
Not sure if this is still in progress or how it relates to the other Haskell PR, but the |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jackc
Oct 15, 2016
Contributor
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.
|
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
closed this
Oct 15, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
bitemyapp
commented
Oct 15, 2016
|
@jackc |



bitemyapp commentedSep 3, 2016
•
edited
Edited 1 time
-
bitemyapp
edited Sep 3, 2016 (most recent)
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.