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

On Thu, 8 Jun 2006, Joel Reymont wrote:

On Jun 7, 2006, at 10:20 PM, S. Alexander Jacobson wrote:

...

Does this make sense?

Makes sense but almost sounds too good.

:-) To be clear, the separation via binary streams has not yet been implemented. I plan to do so only if I need it. If you get to that scale first, then you get to do it :-/. FYI, I am currently funding a modification to HAppS back end logging/persistence system to allow the user to switch easily between disk and Amazon S3. For my apps, I'm willing to add 1.5x S3 latency in exchange for not having to worry about maintainin a reliable RAID disk subsystem with hardware failover and managing off-site backup. Not sure whether this feature is useful for your intended apps.

What package would you recommend I use with HAppS to merge HTML templates with application data?

My apps including Pass.net use XSLT. For HTTP, HAppS looks at the user-agent and if the browser does XSLT then it serves out XML with an XSLT PI at the top. If the browser doesn't support XSLT then it run xsltproc on the server. I don't think any MUA implements XSLT so the XML mail sending agent runs all outbound mail through xsltproc on the server. Note: the implementation of browser xslt detection here is very warty. I'd love it if someone else wanted to take some time to clean it up. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com