Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Here's a comparable Haskell server, warts and all

    {-# LANGUAGE OverloadedStrings #-}
    import Snap
    import qualified Data.ByteString as BS
    
    main :: IO ()
    main = httpServe (setPort 8000 emptyConfig) $ writeBS $ BS.replicate (1024*1024) 100

I'm benchmarking it currently, but my laptop's network stack seems to break ab. It's also probably faster to build the response incrementally using an Enumerator, but I've never used Snap's Enumerator library and this is slightly closer to the design being tested in the other servers since it'll allocate the whole bytestring instead of writing it lazily.


I tried this, the other Haskell version, and the go and node version from op -- with some rather ridiculous ab-values -- the end result was that both of the haskell versions crashed after around 8k requests, while both the go and node-versions completed -- with no missed requests.

I don't have the full numbers (didn't log them) -- but running "ab -n 100000 -c 1000 http://localhost:8000/ -- nodejs completed in 160 seconds, go in 170 seconds. Nodejs had a few requests around 8 seconds, and go had a worst time of almost 5 seconds. (This is on an old desktop, with a core 2 duo - roughly 6000 "bogomips" pr core, two cores).

I'm guessing the haskell solutions ran out of resources, but I'm not sure.


Because this isn't the same benchmark, did you compile with -O2? The Go version allocates a 1MB slice once and sends it to every user. The Haskell version literally states that it should make a bytestring during every request. The compiler might optimize it away with the right flags.


I tried the benchmark as in the article, and the above Haskell compiled with '-O2'. With Go I usually get around 1320 reqs/second, with Snap around 1100. Both using four threads.

With a single-threaded Warp instance, I could get around 1350 reqs/seconds, though it failed dramatically when I used more threads.


No, I didn't (see my other comment). I expect (especially Haskell) to be correct without -O2 -- being slower isn't a problem - crashing - not so much.

Tried it now -- both haskell versions crash with -O2 as well (and ab -n 100000 -c 1000 -- so not the same benchmark as the original -- and a rather silly test).


Not sure, I'm trying to replicate it but I'm having a tough time with OSX's network stack. I can't siege or ab very well. The Haskell server tends to stay under 6Mb on my machine though. I'll keep stressing it.

http://imgur.com/b89bxST




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: