Discussion  - 
Johan Tibell's profile photoKrzysztof Skrzętnicki's profile photoMichael Snoyman's profile photoIC Rainbow's profile photo
but the standard random generator still is!
ah, i see, i think? i don't know yesod very well so i still have no idea where those functions even get invoked/dispatched to?
In getDB2R they are creating a new StdGen object for each element in the array they're generating. Creating a single StdGen and using randonRs instead of randomR should be significantly faster.

Edit: Testing this idea in isolation (eg generating lists of random integers) showed a 4-5 fold speedup.
Is someone preparing a pull request?
Ok, one single problem I found was with cookies. Turns out for requests this small it is a pretty big overhead. If I disable session backend with this code (is it correct?):

instance Yesod App where
    approot = ApprootMaster $ appRoot . settings
    makeSessionBackend _ = return Nothing

Then the performance jumps from

  100000 requests in 5.65s, 38.81MB read
  100000 requests in 2.69s, 17.83MB read

Note that the amount of data read is much smaller.

So in this particular benchmark the cookies are at least partly to blame too.
Looks like most of the issues have been addressed already. I haven't had a chance to play with this myself yet, but I'll try to have a peek at the code today, particularly the JSON code, to see what's slowing it down.
Would be good to get the website author to update the numbers with the fix
Take this with a grain of salt, because I'm not using their benchmark setup. Instead, I'm just testing on my local system and using ab. I get the following req/sec:

7874.52 original
24097.85 new yesod
37311.19 WAI
23242.75 yesod 1.2 w/parseRoutes
29966.72 yesod 1.2 lower level
25248.16 netty

In my testing, I didn't pass in any -N options. Until the new I/O manager comes out in 7.8, running on multiple cores might actually slow down the results (it did on my local system at least).
Every time i look at benchmark olympics like this one i think "huh.. whatever. I use haskell because of no-bullshit approach to correctness, the numbers are just an icing on a cake."
Add a comment...