[Haskell-cafe] HAppS in production?
S. Alexander Jacobson
alex at alexjacobson.com
Wed Jun 7 17:20:42 EDT 2006
On Wed, 7 Jun 2006, Joel Reymont wrote:
> What type of machine are you running this on?
> What type of memory usage are you seeing?
> Under what kind of load?
> How much memory per connection?
"darcs get http://pass.net/s/repo" and you can experiment for
yourself. If you have SearchPath installed <http://searchpath.org>
you just run "sh build.sh" in the Pass.net root directory. FYI, I do
development on a windows machine and deployment is on an old 1and1 web
> Are you running the naked HAppS web server?
I have multiple HAppS applications running on different internal ports
on the default 1and1 machine. Some of them are only handling http.
Others are handling inbound email as well. So for http, I am using
Apache as a secure server side caching proxy that dispatches
http(s)://pass.net to localhost:9000 and I am using sendmail to SMTP
relay mail for certain domains to e.g. localhost:2525 But, if this was
the only app on the machine, I probably would run HAppS naked.
> Have you done any time of performance testing?
Our internal benchmark tests had simple HAppS apps performing faster
than Apache. But these sorts of tests are very application dependent
so you will have to test your own apps.
FYI, we have achieved this level of performance without doing much in
the way of optimization. If you truly have a need for speed, the nice
thing about HAppS is that the MACID monad architecture gives you
orders of magnitude headroom for certain sorts of applications.
In particular, currently HAppS works as an integrated binary that
aggregates events from the network into a totally ordered stream that
is then processed sequentially by your application code. But it would
not be all that hard to separate the code into processes that creates
streams, proceses that merge/distribute streams, and one process that
runs your app on the merged stream.
In this sort of architecture all of the work of HTTP and TCP gets
offloaded onto stream creators running slave machines and your app
effectively operates as a process that simply reads a binary parsed
stream from stdin and writes one to stdout.
To see why this gives you so much performance headroom, think about
operating a sequential number service. A sequential number service is
a service that produces numbers in order with no gaps. Notice that
this is a really really simple service. But also notice that the
standard web site architecture will cap your performance at around 10k
requests per second and you won't be able to improve performance much
by buying new machines!
In contrast by patitioning your HAppS application as I described you
max out at 1m requests per second. Note: I don't know what the cap
is, but reading binary from stdin is orders of magnitude simpler than
prcessing HTTP and TCP so getting a 100x improvement should not be
Does this make sense?
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
More information about the Haskell-Cafe