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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
