4 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 pag

> 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. So every time it receives a request it launches a new Xen instance, processes the request, sends a response, and then kill the Xen instance? And all that takes 600ms just to process a single request? Why would anyone want to do that when I could just have a persistent JVM running on Linux to process requests in under 10ms? What's the point of this?

ithkuil 14y ago
> What's the point of this? to show that's possible. There are certainly better use cases for that. From the top of my head: 1) Per user VM. The first request for a logged in user will spawn a VM and then all requests for her will be routed there 2) Fine grained elasticity control. Currently it's difficult to decide when to spawn new VMs, because it takes time to spawn a new one (and billing is computed hourly, but that's another issue), so it complicated to decide whether to pump up the steam or wait a little bit more. Having a sub-second startup time could help creating better elasticity controls.