Hello, As we all know, the true measure of performance for a web server is the classic PONG test. And, so the Happstack team is pleased to announce the release of the new acme-http server! hackage: http://hackage.haskell.org/package/acme-http source: http://patch-tag.com/r/stepcut/acme-http When testing on my laptop with +RTS -N4 using the classic PONG test: $ httperf --hog -v --server 127.0.0.1 --port 8000 --uri / --num-conns=1000 --num-calls=1000 --burst-length=20 --rate=1000 acme-http delivered 221,693.0 req/s, making it the fastest Haskell web server on the planet. By comparison, warp delivered 51,346.6 req/s on this machine. The secret to acme-http's success is that it large avoids doing anything not required to win the PONG benchmark. It does not support timeouts, it does not check quotas, it assumes the client is HTTP 1.1, it does not catch exceptions, and it responds to every single request with PONG. The goal of acme-http is two fold: 1. determine the upper-bound on Haskell web-server performance 2. push that upper bound even higher In regards to #1, we have now established the current upper limit at 221,693.0 req/s. In regards to #2, I believe acme-http will be useful as a place to investigate performance bottlenecks. It is very small, only 250 lines of code or so. And many of those lines deal with pretty-printing, and other non-performance related tasks. Additionally, it works in the plain IO monad. It does not use conduits, enumerators, pipes, or even lazy IO. As, a result, it should be very easy to understand, profile, and benchmark. In providing such a simple environment and avoiding as much extra work as possible we should be able to more easily answer questions like "Why is so much RAM required?", "What is limiting the number of connections per second", etc. As we address these issues in acme-http, we can hopefully bring solutions back to practical frameworks, or to the underlying GHC implementation itself. If performance tuning is your thing, I invite you to check out acme-http and see if you can raise the limit even higher! - jeremy
On Sun, Apr 1, 2012 at 8:46 PM, Jeremy Shaw
Hello,
As we all know, the true measure of performance for a web server is the classic PONG test. And, so the Happstack team is pleased to announce the release of the new acme-http server!
hackage: http://hackage.haskell.org/package/acme-http
source: http://patch-tag.com/r/stepcut/acme-http
When testing on my laptop with +RTS -N4 using the classic PONG test:
$ httperf --hog -v --server 127.0.0.1 --port 8000 --uri / --num-conns=1000 --num-calls=1000 --burst-length=20 --rate=1000
acme-http delivered 221,693.0 req/s, making it the fastest Haskell web server on the planet.
By comparison, warp delivered 51,346.6 req/s on this machine.
The secret to acme-http's success is that it large avoids doing anything not required to win the PONG benchmark. It does not support timeouts, it does not check quotas, it assumes the client is HTTP 1.1, it does not catch exceptions, and it responds to every single request with PONG.
The goal of acme-http is two fold:
1. determine the upper-bound on Haskell web-server performance 2. push that upper bound even higher
In regards to #1, we have now established the current upper limit at 221,693.0 req/s.
In regards to #2, I believe acme-http will be useful as a place to investigate performance bottlenecks. It is very small, only 250 lines of code or so. And many of those lines deal with pretty-printing, and other non-performance related tasks. Additionally, it works in the plain IO monad. It does not use conduits, enumerators, pipes, or even lazy IO. As, a result, it should be very easy to understand, profile, and benchmark.
In providing such a simple environment and avoiding as much extra work as possible we should be able to more easily answer questions like "Why is so much RAM required?", "What is limiting the number of connections per second", etc.
As we address these issues in acme-http, we can hopefully bring solutions back to practical frameworks, or to the underlying GHC implementation itself.
If performance tuning is your thing, I invite you to check out acme-http and see if you can raise the limit even higher!
- jeremy
-- You received this message because you are subscribed to the Google Groups "HAppS" group. To post to this group, send email to happs@googlegroups.com. To unsubscribe from this group, send email to happs+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/happs?hl=en.
That's awesome! I think you should pair this up with the /dev/null datastore and then you'll be truly webscale! Michael
On Sun, Apr 1, 2012 at 12:48 PM, Michael Snoyman
That's awesome! I think you should pair this up with the /dev/null datastore and then you'll be truly webscale!
Well, acid-state does have a backend that skips writing any transaction logs to disk making it pure memory based: http://hackage.haskell.org/packages/archive/acid-state/0.6.3/doc/html/Data-A... So, that is a bit like a /dev/null data store. It works really great as long as your app never restarts :) - jeremy
participants (2)
-
Jeremy Shaw -
Michael Snoyman