3 ms·
" 0.6 sec ago is when we received your request. Within this time we managed to create a new Xen instance, boot it, and run the application that rendered the pa
by arb99 14y ago
"
0.6 sec
ago is when we received your request. Within this time we managed to create a new Xen instance, boot it, and run the application that rendered the page you are viewing. By the time you are done reading this, the instance will be gone.
"
for a basic page like that is a bit slow...
- peteretep 14y agoPresumably the idea is that you run a pool of them, so you're not spawning a new instance each time?
- mmcnickle 14y agoI got the impression that you _are_ expected to spawn a new instance each time.
- smosher 14y agoI 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.
- peteretep 14y agoMy 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?
- smosher 14y agoThanks 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.
- arb99 14y agofair enough. was just pointing it out as it is presented as if it is fast for a page load time. neat project though.
- smosher 14y agoIt 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.
- jlouis 14y agoTrue, 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.
- viktorsovietov 14y agoBEAM ("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.
- dons 14y agoWhile halvm boots in the 10ms range (like starting a GHC process). These can be very fine grained and fast.