4 ms·

Sure! Over the course of yesterday we had 747 demo users launch 952 app instances. Currently we're on GCE for price reasons, though we're looking for good non

by kentonv 12y ago

Sure! Over the course of yesterday we had 747 demo users launch 952 app instances. Currently we're on GCE for price reasons, though we're looking for good non-Google, non-Amazon options for our eventual release. Sandstorm tends to be memory-bottlenecked since we're launching separate instances of each app for each user, although we make up a lot of it by shutting down instances when they aren't in active use. I was super-paranoid about the demo totally breaking under load (having not tried this before), so I upped the server to GCE's largest-memory instance at 104GB of RAM. That turned out to be completely unnecessary. It never used more than 6GB (and CPU was mostly negligible). Doh. Oh well, better to have spent too much than too little. We also have a separate front-end server which does our SSL, so that our private keys don't reside on the same server as apps, just as an extra precaution. That machine is just a regular n1-standard-1 instance. CPU usage was in the single digit percentages there as well. You can indeed run your own Sandstorm instance. There are installation instructions in our Github readme: https://github.com/sandstorm-io/sandstorm https://github.com/sandstorm-io/sandstorm Feel free to send me questions.

e12e 12y ago
Thanks for the detailed reply. I had some trouble building the whoke thing under Debian stable (with a 3.14 kernel from backports, trying to force everything to work under my user id in $HOME/opt. Not too surprising. Meteor serms to be part of the problem (got it working with its self-contained binary install) - as well as the apparent need for a newer libfuse and some c++ headers I couldn't quite figure out. Although I was building with clang-3.5). I'll have a go at getting the vagrant box up, and then trying again in a Debian testing vm/chroot. If that fails, I'll have to go with an ubuntu vm/chroot :-) At any rate, sounds like my 4 core gbuplink hetzner box with 16gb ram should have no problem working with this (obviously overkill for a personal playpen, but its good to know I have lots of headroom...). Are you planning to stay with meteor going forward? The other components seem much less complicated to get up and running, and more sys.adm. friendly. An example being the need (?) for node/npm and meteor's bundled node/npm...
- kentonv 12y ago
  It sounds like you were installing from source. There are indeed a lot of moving parts to deal with there. We also have a binary installer (and auto-updater) which "just works" with essentially no dependencies. I understand some people aren't comfortable with binary installers, but you have to understand that building from source will always be more work. :) That said, feel free to file issues for any obstacles you encounter that aren't already covered in the docs. We do plan to stick with Meteor. It's a pretty awesome framework. I find Meteor is incredibly easy to get running, but this is again due to its binary installer script which maybe you don't like. :) I believe that Meteorite (the "mrt" tool which you had to install separately using npm) is slated to go away before Meteor 1.0 as that functionality will be rolled into Meteor itself. So, that part will get better, at least. For now, you actually can (and arguably should) install it using Meteor's bundled npm rather than the system npm.
  - e12e 12y ago
    Actually, the mrt tool wasn't a problem (I had node installed from source, in my home-dir under opt from before -- working quite well with xstow. Meteor not installing from source is partly due to me running Debian stable -- I'm not surprised when bleeding edge frameworks won't compile, just a little bit disappointed ;). I was indeed installing from source, as that is a requisite for contributing to the project (if I can't build it how could I possibly submit patches). I have no problem with you citing any one distribution/version as supported however -- it would be madness to demand support for "everything" from an alpha source release! And I think aiming for cross-platform-distribution comparability would be wasted effort at this point. With Vagrant from wheezy-backports, everything came up fine -- just had to(?) increase the vms ram to 512 mb for ipython notebook to work. Now my only problem is figuring out how to get the hacker cms to publish anything (to users without login). I've understood that the cms should be stuffing files under /var/www (in my vagrant/virtualbox vm) -- so I'll have to check if "publish" pushes anything there -- and if there appear to be an nginx-instance set up to serve files from /var/www...). As for meteor -- I have a few reservation of their architecture in general -- but my main problem is the complexity of the setup -- especially how hart it seems to be to build everything needed from source. But then again, they're not yet at 1.0, are they? (Still seeing as how easy nodejs is to build from source, it is a shame meteor manage to somehow mangle that process...)

by kentonv 12y ago

e12e 12y ago

Thanks for the detailed reply. I had some trouble building the whoke thing under Debian stable (with a 3.14 kernel from backports, trying to force everything to work under my user id in $HOME/opt. Not too surprising. Meteor serms to be part of the problem (got it working with its self-contained binary install) - as well as the apparent need for a newer libfuse and some c++ headers I couldn't quite figure out. Although I was building with clang-3.5). I'll have a go at getting the vagrant box up, and then trying again in a Debian testing vm/chroot. If that fails, I'll have to go with an ubuntu vm/chroot :-) At any rate, sounds like my 4 core gbuplink hetzner box with 16gb ram should have no problem working with this (obviously overkill for a personal playpen, but its good to know I have lots of headroom...). Are you planning to stay with meteor going forward? The other components seem much less complicated to get up and running, and more sys.adm. friendly. An example being the need (?) for node/npm and meteor's bundled node/npm...

kentonv 12y ago
It sounds like you were installing from source. There are indeed a lot of moving parts to deal with there. We also have a binary installer (and auto-updater) which "just works" with essentially no dependencies. I understand some people aren't comfortable with binary installers, but you have to understand that building from source will always be more work. :) That said, feel free to file issues for any obstacles you encounter that aren't already covered in the docs. We do plan to stick with Meteor. It's a pretty awesome framework. I find Meteor is incredibly easy to get running, but this is again due to its binary installer script which maybe you don't like. :) I believe that Meteorite (the "mrt" tool which you had to install separately using npm) is slated to go away before Meteor 1.0 as that functionality will be rolled into Meteor itself. So, that part will get better, at least. For now, you actually can (and arguably should) install it using Meteor's bundled npm rather than the system npm.
- e12e 12y ago
  Actually, the mrt tool wasn't a problem (I had node installed from source, in my home-dir under opt from before -- working quite well with xstow. Meteor not installing from source is partly due to me running Debian stable -- I'm not surprised when bleeding edge frameworks won't compile, just a little bit disappointed ;). I was indeed installing from source, as that is a requisite for contributing to the project (if I can't build it how could I possibly submit patches). I have no problem with you citing any one distribution/version as supported however -- it would be madness to demand support for "everything" from an alpha source release! And I think aiming for cross-platform-distribution comparability would be wasted effort at this point. With Vagrant from wheezy-backports, everything came up fine -- just had to(?) increase the vms ram to 512 mb for ipython notebook to work. Now my only problem is figuring out how to get the hacker cms to publish anything (to users without login). I've understood that the cms should be stuffing files under /var/www (in my vagrant/virtualbox vm) -- so I'll have to check if "publish" pushes anything there -- and if there appear to be an nginx-instance set up to serve files from /var/www...). As for meteor -- I have a few reservation of their architecture in general -- but my main problem is the complexity of the setup -- especially how hart it seems to be to build everything needed from source. But then again, they're not yet at 1.0, are they? (Still seeing as how easy nodejs is to build from source, it is a shame meteor manage to somehow mangle that process...)