You know, the idea sure is impressive, but getting over capacity errors sure doesn't show it well :)
Zerg demo – Xen instance spawned for each web request
21–30 of 39 posts
Re: Zerg demo – Xen instance spawned for each web request
#22zerg rush is imba (get the joke? ha... sorry)
Re: Zerg demo – Xen instance spawned for each web request
#23You know, the idea sure is impressive, but getting over capacity errors sure doesn't show it well :)
On the contrary I like it. They have finite resources and it answers immediately with the correct response.
Re: Zerg demo – Xen instance spawned for each web request
#24Can someone shine some light on why and how this is useful? What are some examples?
If you've ever had to scale capacity on AWS (or any other on-demand cloud service, really) you'd know. On the page they say 300 seconds to bring up a Linux instance, but really that can even take longer from time to time.
When you need to scale in a hurry (or in this case semi-automatically), the ability to launch persistent or temporary VM instances in a much shorter timeframe is critical.
Granted (and as they note here) this is sort of demo-only, and probably not particularly useful out of the box. But as a demonstration of how fast things could work it's perfect. It doesn't hurt that it's functional.
Re: Zerg demo – Xen instance spawned for each web request
#25I'm seeing 1.5 to 1.6 secs. Is that due to my crappy internet connection or is that simply what it is? Because 1.5 secs per request, and more for somewhat more complex operations, seems long to me. As instance startup time it is impressive though! But they are designed to die after each request, right? Or is that just this example?
I got 3 seconds.
But that isn't 3 seconds to serve the page. That's 3 seconds to basically build and boot the "server" on-demand, start all necessary daemons and serve the page.
Now think about what happened when you needed to add a Web server 10 years ago.
Re: Zerg demo – Xen instance spawned for each web request
#26You know, the idea sure is impressive, but getting over capacity errors sure doesn't show it well :)
On the contrary I like it. They have finite resources and it answers immediately with the correct response.
This. With typical web applications, your request would wait until something times out and cascades back to the client (webserver, app server, db, etc.). This can mean waiting for 30 seconds or more depending on your configuration.
It's not an easy problem to solve elegantly too.
Re: Zerg demo – Xen instance spawned for each web request
#27This is really neat stuff. I do not understand though why LING is not open-source already. If you are sincere in your claims for intentions of making it so, why would you wait until it is "mature" before doing so? Wouldn't it mature a lot faster if more people picked it up and tried to use it, submitted defects and even patches?
Re: Zerg demo – Xen instance spawned for each web request
#28Can someone shine some light on why and how this is useful? What are some examples?
The folks at ZeroVM have a list of motivations[1] for this type of execution and hosting model. The only problem is that it's hard to tell how active the project is from their main page alone.
EDIT: Their github commit is fairly active for a solo developer[2].
Re: Zerg demo – Xen instance spawned for each web request
#29This is really neat stuff. I do not understand though why LING is not open-source already. If you are sincere in your claims for intentions of making it so, why would you wait until it is "mature" before doing so? Wouldn't it mature a lot faster if more people picked it up and tried to use it, submitted defects and even patches?
I'm afraid, only few people are familiar with internals of Erlang VM, especially, if that VM is totally different from BEAM. Thus, there's no reason to opensource it, at least yet. Though, build.erlangonxen.org is open, contains the most recent stable version, and free to use.
Re: Zerg demo – Xen instance spawned for each web request
#30Earlier quoted context omitted.
On the contrary I like it. They have finite resources and it answers immediately with the correct response.
This. With typical web applications, your request would wait until something times out and cascades back to the client (webserver, app server, db, etc.). This can mean waiting for 30 seconds or more depending on your configuration. It's not an easy problem to solve elegantly too.
It actually is quite easy if you set a finite limit on connections and show an appropriate message to those connections you're actively refusing. If you're allowing as many connections as your server/network/database can allow, it might take a bit longer to determine a failure status.