6 ms·

I find it a little embarrassing that a blog about a web framework fails to load (though perhaps that's a little unfair considering a HN traffic spike). Especial

I find it a little embarrassing that a blog about a web framework fails to load (though perhaps that's a little unfair considering a HN traffic spike). Especially since I thought one of Yesods main advantages was performance. For the lazy (pun intended) his Conclusions are: - Java-the-language and Java-the-libraries make a number of simple tasks very complicated. - Therefore, we have a number of helper languages, like XSLT and Ant, to avoid the pain of a pure Java solution. - However, these tools are all purposely missing some features we'll inevitably need. - The result will be either missing proper handling of some features, a polyglot that will miss the point of using Java in the first place, or most likely both. - There are great use cases for non-general-purpose languages, but they should have tight integration with a real language. - Haskell's flexible syntax and great typing make it very powerful here. I just spent last weekend putting together a Yesod web app and am very sympathetic to his mantra. Hamlet is a lovely language (valid HTML is valid Hamlet so very easy to pick up) that does one thing well, one thing well, and nothing else. It very easily allows me to go back into Haskell if I need to. The key is that Hamlet is merely syntactic sugar. Ant isn't just syntactic sugar, its far more than that, which makes it different.

willismichael 14y ago
> Especially since I thought one of Yesods main advantages was performance. Performance and scalability are two different things.
- polymatter 14y ago
  Well I have much to learn. But given that Haskell is easy to parallelise (compared to Ruby or Java), and compiles to very fast object code to boot, it seems like it should be able to withstand HN traffic better than the average blog that gets featured here. Its a little embarrassing because yesodweb.com is the main Yesod website, not some amateur like me hacking stuff together.
  - willismichael 14y ago
    Fair enough, I'm just assuming that even given the capability to parallelise, they probably just don't have the necessary amount of hardware provisioned to cope with HN-magnitude traffic spikes.
    - profquail 14y ago
      The site seems to be running on AWS, so you're probably right. It's loading very quickly now though so I imagine they've upgraded to a bigger instance.
    - jules 14y ago
      That's hardly an excuse given that HN itself runs on 1 core, and just a fraction of that traffic will be going through to this post.
      - deleted 14y ago
        [deleted]
jcromartie 14y ago
If Yesod is about performance, it's not showing: http://www.techempower.com/blog/2013/04/05/frameworks-round-2/ http://www.techempower.com/blog/2013/04/05/frameworks-round-...
- polymatter 14y ago
  Well, thanks for the data.
- DannoHung 14y ago
  Be sure to check community commentary on the implementations that were tested before deriving any conclusions: http://www.reddit.com/r/haskell/comments/1bqsvi/web_woes_for_haskell http://www.reddit.com/r/haskell/comments/1bqsvi/web_woes_for...
  - profquail 14y ago
    For the lazy: The reason for Yesod's poor showing in that benchmark was due to a flaw in the implementation of the benchmark. A certain function (newSTDGen) was called repeatedly within each request, even though it should have only been called once; it's a relatively "expensive" function so this had a large impact on the results of the test. In addition, the Yesod test used TCP sockets to communicate with MySQL while the other frameworks were set to use UNIX sockets. This has also been found to have a non-trivial impact on performance, as discussed in this SO thread: http://stackoverflow.com/questions/257433/postgresql-unix-domain-sockets-vs-tcp-sockets http://stackoverflow.com/questions/257433/postgresql-unix-do...
    - papsosouid 14y ago
      >A certain function (newSTDGen) was called repeatedly within each request It is called zero times in the json benchmark, which yesod still did quite poorly on. That is only a factor in the "pull a random thing from the DB" test. I believe the biggest underlying issue was that sessions are enabled, which means transmitting more data (the cookie) as well as doing encryption and HMAC on the cookies. Disabling sessions doubled the performance.

willismichael 14y ago

> Especially since I thought one of Yesods main advantages was performance. Performance and scalability are two different things.

polymatter 14y ago
Well I have much to learn. But given that Haskell is easy to parallelise (compared to Ruby or Java), and compiles to very fast object code to boot, it seems like it should be able to withstand HN traffic better than the average blog that gets featured here. Its a little embarrassing because yesodweb.com is the main Yesod website, not some amateur like me hacking stuff together.
- willismichael 14y ago
  Fair enough, I'm just assuming that even given the capability to parallelise, they probably just don't have the necessary amount of hardware provisioned to cope with HN-magnitude traffic spikes.
  - profquail 14y ago
    The site seems to be running on AWS, so you're probably right. It's loading very quickly now though so I imagine they've upgraded to a bigger instance.
  - jules 14y ago
    That's hardly an excuse given that HN itself runs on 1 core, and just a fraction of that traffic will be going through to this post.
    - deleted 14y ago
      [deleted]

jcromartie 14y ago

If Yesod is about performance, it's not showing: http://www.techempower.com/blog/2013/04/05/frameworks-round-2/ http://www.techempower.com/blog/2013/04/05/frameworks-round-...

polymatter 14y ago
Well, thanks for the data.
DannoHung 14y ago
Be sure to check community commentary on the implementations that were tested before deriving any conclusions: http://www.reddit.com/r/haskell/comments/1bqsvi/web_woes_for_haskell http://www.reddit.com/r/haskell/comments/1bqsvi/web_woes_for...
- profquail 14y ago
  For the lazy: The reason for Yesod's poor showing in that benchmark was due to a flaw in the implementation of the benchmark. A certain function (newSTDGen) was called repeatedly within each request, even though it should have only been called once; it's a relatively "expensive" function so this had a large impact on the results of the test. In addition, the Yesod test used TCP sockets to communicate with MySQL while the other frameworks were set to use UNIX sockets. This has also been found to have a non-trivial impact on performance, as discussed in this SO thread: http://stackoverflow.com/questions/257433/postgresql-unix-domain-sockets-vs-tcp-sockets http://stackoverflow.com/questions/257433/postgresql-unix-do...
  - papsosouid 14y ago
    >A certain function (newSTDGen) was called repeatedly within each request It is called zero times in the json benchmark, which yesod still did quite poorly on. That is only a factor in the "pull a random thing from the DB" test. I believe the biggest underlying issue was that sessions are enabled, which means transmitting more data (the cookie) as well as doing encryption and HMAC on the cookies. Disabling sessions doubled the performance.