ANN: acme-http

[Jeremy Shaw-3]

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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Michael Snoyman]

On Sun, Apr 1, 2012 at 8:46 PM, Jeremy Shaw <[hidden email]> wrote:

> 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 [hidden email].
> To unsubscribe from this group, send email to [hidden email].
> 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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Jeremy Shaw-3]

On Sun, Apr 1, 2012 at 12:48 PM, Michael Snoyman <[hidden email]> wrote:

> 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-Acid-Memory.html

So, that is a bit like a /dev/null data store. It works really great
as long as your app never restarts :)

- jeremy

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe