Presumably the idea is that you run a pool of them, so you're not spawning a new instance each time?

I got the impression that you _are_ expected to spawn a new instance each time.

My impression is that the fast loadup is for scaling upwards as needed. I am only expecting it to spawn a new piece if I am the first person whose request can't be answered as part of a wave of unexpected traffic... Why else would you want this?

I think so too. But simple pages in this configuration just measure nginx performance (check the breakdown)—that's a good sign for the rest of the process.

True, but the Erlang VM is not really written for fast startup. Module loading is serial and not parallel. The key here is that you can scale up in 0.6 seconds, which is awfully much faster than most other solutions, where scaling takes minutes.

BEAM ("official" Erlang VM) starts much longer. Erlang On Xen has it's own VM (written from scratch), it was designed for run without OS and to srtart very fast, particularly.

While halvm boots in the 10ms range (like starting a GHC process). These can be very fine grained and fast.

Thanks for pointing it out, I gave me an excuse to look at the numbers:

I took 4.6 seconds when I loaded it. In the breakdown ~4.3s of that was nginx dicking around (probably spending much of its time telling people it can't spawn an instance right now.) The lightweight nature of the page is obviously exposing the nginx overhead, which is turning out to be a bottleneck. Based on all that: with more complex pages, a more realistic limit on instances and similar resource utilization, I would expect it to be down right snappy.

fair enough. was just pointing it out as it is presented as if it is fast for a page load time. neat project though.

It is a good point, when the load time is measured in seconds it doesn't leave one with the impression that it's fast. It would be better to see it serving with a more realistic configuration.