[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 
server.

> 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 
that hard.

Does this make sense?

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com


More information about the Haskell-Cafe mailing list