Pools: Arbitrary HTTP Servers, Resource Reservation and Scalability

We are pleased to announce that we are beginning the beta of our new “pools” service. Pools are a way to reserve memory and CPU power for one or more web sites. This approach makes it possible to discard many of the limitations traditionally associated with our service.

Pool vs. VPS

I’m really trying to avoid saying “it’s like a VPS” although it shares DNA with that approach: isolation by virtualization, resource guarantees, and scalability. Because despite those similarities, it’s equally notable for its differences. Like our traditional service, and unlike a VPS, pools take advantage of our core infrastructure: firewalls, HTTP accelerators, and high-performance file servers. Also unlike a VPS, pools include our 24x7x365 operational monitoring and maintenance of the OS, network stack, and software environment.

It’s not as cut and dried as saying “Pools are better than VPSs,” or the other way around. In keeping with our “we host web sites” mantra, Pools are extremely optimized for awesome hosting of web applications; they don’t really do anything else. For hosting the world’s Ventrillo, Shoutcast, IRC bots and servers, and all that other stuff, a “typical” VPS is still the only way to go, and we’re grateful that other people offer that service, because we have no interest in doing it.

There are a couple of key factors to look at to determine whether you’re better off with a pool or with a VPS.

Is it a web (port 80) application?

Yes -> Pool

No -> VPS

You want:

Root access and maximum control over OS choice and tuning. -> VPS

To focus on your site and leave the security updates, firewalls, and midnight outages to a team of experts. -> Pool

You need a dedicated IP address or SSL support:

Yes -> VPS

No -> Pool

Pool Pricing

(As with all things beta, the information here is subject to change as we refine what we can and can’t do.)

Pools are priced based on RAM, but include both a RAM and CPU component. (The difference being that CPU usage is burstable and RAM is not.) The specific CPU amounts are still be determined, but the minimum reservation will, somewhat obviously, be proportional to the ratio of Ghz to GiB in the standard blades we use. We inevitably run out of RAM before CPU power, and we don’t expect that to change, so the “burst” CPU amounts available should be substantial.

The base price for a pool is $3.43/month. Each gigabyte of RAM is $21.45/month. That means you can get a 1GB pool of dedicated RAM for less than $25/month.

However, since this is NearlyFreeSpeech.NET, all “monthly” charges are based on 31-day months and calculated to the penny in real time.

Pool Sizing

There are no packages or bundles. Pools can be configured at any memory size you desire between a minimum of 128MiB ($6.11/month) and a maximum of 3GiB ($67.78/month) in 4mb increments, and the memory size can be changed at any time with a simple “reboot” that takes about 20-30 seconds.

There is one “catch.” When sizing your pool, keep in mind that there is some overhead. There is baseline OS overhead of about 40MiB plus about 8MiB per GiB. (We could theoretically do a 64MiB pool, but the overhead would leave about 24MiB available for your web server. So it’s technically cool, but not terribly practical.)

If you’re not sure how much memory you need, we recommend starting with 128 MiB ($6.11/month) or 256 MiB ($8.43/month).

Storage Pricing Offset

As most people know, our charge for disk storage is how we have traditionally recovered the equipment costs (including CPU and RAM). Obviously pools represent a very different approach, and it would be “double dipping” to charge both fees at the same time.

Thus, at least for the first part of the beta, 90% the storage charges that accrue for sites that are assigned to pools will be used to offset the cost of the pool. For example, if you currently pay $5.00/month for storage for your site example, and you convert it to a pool, you will get up to a $4.50/month offset against the cost of the pool.

That’s not the long term solution to making storage pricing more fair, it’s more of a band-aid. We will be adjusting this down the road.

Pools and Lanes

It’s possible to run more than one site inside a pool. Pools can be divided into multiple “lanes,” each of which can host a completely separate site. (Picture competitive swimmers and the little floaty things that separate their lanes.) Sites in different lanes of the same pool share the RAM and CPU of the pool, but have “logical” isolation; they cannot interact or see each other and might be running completely different configurations or web servers.

Apache Lanes

We provide an Apache 2.2 build that works great with pools. It comes with PHP 5.2 and 5.3 support available, both of which run with safe_mode off and at a significant performance boost over PHP Fast. It’s great for heavy frameworks like Zend and provides a particularly nice boost to hard-hit sites running CMS applications like Drupal.

But not only is it faster than PHP Fast, it’s also more flexible than PHP Flex. You get full control over your httpd.conf and php.ini files. Need custom PHP extensions? No problem. Want mod_ruby or mod_perl instead? No problem. Add what you need. Want mod_deflate or mod_dav? You can make it happen.

Arbitrary Server Lanes

What if you don’t want to run Apache at all? Still no problem. Inside a pool, it is possible to run any web server or application. Zope, Rails, Catalyst, Tomcat; pretty much anything that talks HTTP on port 80 will work. The only restriction we impose is that it has to be able to run in “foreground” or “monitored” mode. (That’s just so that our system can keep an eye on it and make sure it stays running.)

How do I get in the beta?

We have added an assistance request for the Pool beta. The initial allocation of resources for the beta will be limited, and since pools represent a resource reservation, beta opportunities may be limited as well. We will get as many people into the beta as quickly as we can, but we may have to delay some requests if it proves too popular.

The Future of Pools

Initially, at least for the duration of this beta, pools will be most suitable for larger sites due to the nontrivial per-pool overhead; it’s not shared hosting and can’t be priced that way. However, part of the purpose of the beta is to help us finalize the development and testing of the underlying technology to get it to the level where we can offer a related option that will make it cost-effective for even very small sites to get the security, performance and flexibility offered by pools.

This is really exciting stuff for us, and we hope you’ll check it out and help us make it even better, both by giving us beta feedback and by using it to do amazing stuff we never would have thought of.

27 Comments

RSS feed for comments on this post.

1. Bravo! This sounds great.

   Comment by ttuttle — April 3, 2010 #

2. This is a very creative and useful idea. It provides many of the benefits of a VPS or dedicated server plus monitoring and management. The pay as you go pricing model and the quality of the NFSN management team should make this an excellent option.

   Comment by fos — April 3, 2010 #

3. If I have my math right, for a 1.7 GB instance, you charge $39.89/month and Amazon charges $63.24/month. Of course, Amazon’s bandwidth is an order of magnitude cheaper, but even this apples-to-oranges comparison is pretty impressive.

   This means you guys can now support Django as well, right?

   Comment by Braden — April 3, 2010 #

4. Amazon’s bandwidth pricing is $0.15/GiB for up to 10TB per month. Ours is $0.20/GiB if you’ve ever transferred 10TiB. I don’t think I would call that an order of magnitude difference, and if somebody does 10TB/month, we’ll work with them. (I agree the current 90TiB to get from $0.20/GiB to $0.16.6666/GiB is too much in such a case.)

   On Django, I haven’t personally worked with it, but I believe it uses WSGI and I believe mod_wsgi in “embedded mode” should work just fine.

   -jdw

   Comment by jdw — April 3, 2010 #

5. This sound great. Some questions:
   Will mod_wsgi in daemon mode be supported?
   Will custom HTTP servers be supported?
   Is it possible to run reverse proxy inside the pool, proxying to other servers within it?
   What is the server restarting process, is it just the regular “/etc/init.d/… restart” in an ssh session or is it something different?

   Comment by Sergey — April 3, 2010 #

6. mod_wsgi in daemon mode… I don’t know.

   “Support.” We won’t provide tech support or configuration assistance for anything but our Apache server (and even that will definitely be paid support). As far as what custom HTTP servers you can get to work on your own, as long as it meets the requirements, it will work.

   In theory you could have two different sites in two different lanes in the same pool and reverse proxy from one to the other. Since we already use reverse proxies, it would probably be tough to find a case for such an approach that would justify the overhead.

   Soon you will be able to hup/kill/start/stop the process from the UI. Until we get the kinks ironed out from that, you’ll have to use an assistance request and have us do it. (That’s going to be tedious, so expect us to get the kinks ironed out really fast. 😉 )

   There is absolutely no connection between ssh (which is a shared resource) and the isolated processes running in your pool, other than they share files.

   -jdw

   Comment by jdw — April 3, 2010 #

7. Thank you for your answers.

   By “support” I meant “allow to run”, so that’s fine.

   What are the requirements for the servers? (I assume they are work in progress, so is there some wiki page or a forum thread which we can track to see them get fleshed out?)

   Is it possible to restart the server without going to the UI? This is important for code updates when the server needs to restart to pick up the changes, so the deployment script would need to be able to restart the server.

   Regarding SSH, am I correct assuming that it will be impossible to log into the server itself? I imagine that would make some of the maintenance tasks much harder, so if you could tell a little more about what exactly will be possible to do with the pool, that would be much appreciated.

   Comment by Sergey — April 3, 2010 #

8. I’m so glad this wasn’t an April Fools gag! This sounds really exciting. Does this include support for any Apache module and things like FastCGI? I mean, if I could find binaries or source for any Apache module, could I upload it to the server and install it without having to have you guys intervene at all?

   Comment by Jasper — April 4, 2010 #

9. Technically I guess you could restart the server via the NFSN API but I don’t really understand the reason why you would restart a web server in order to pick up code changes.

   Sounds like a very nice offer from NFSN for larger sites which would have so far been very expensive to run.

   Comment by Martin Tsachev — April 4, 2010 #

10. Will pricing pool users still be charged for mysql processes and php enabled (aka dynamic) websites? I would think these fees shouldn’t be charged if ram and cpu resources are reserved.

    All pool-contained sites are considered dynamic for system administration purposes, and MySQL does not run within the pool, so those fees aren’t affected by whether or not you use this feature. -jdw

    Comment by Greg — April 4, 2010 #

11. Will there be any sort of support for wildcard DNS?

    That’s a fair question. We will have to give some thought to how that would be done. -jdw

    Comment by Chris — April 4, 2010 #

12. Sergey:

    See the “Arbitrary Server Lanes” section of the post for the requirements. It’s a short list.

    It would indeed be possible for us to add process/lane control actions to the API in the future, and we will probably do that, but most servers will be able to restart themselves if needed by sending their parent process the appropriate signal, so you could always implement that yourself.

    It will indeed not be possible to “log in” to a pool in any traditional sense. Most maintenance tasks would be performed by some combination of using our ssh server to manipulate the site’s filesystem and using our UI to start/stop/restart/whack the server process to respond to changes.

    Jasper:

    You can definitely bring your own Apache module (BYOAM?) and add it with LoadModule. I’m not sure if FastCGI will run (well), but you can certainly give it a shot. It would depend on whether the Apache server will do a good enough job of starting/stopping the FastCGI daemon at appropriate times.

    -jdw

    Comment by jdw — April 4, 2010 #

13. This sounds really good.

    Will Cherokee or nginx run on this new platform?
    They are much faster than apache.

    You could probably get them to run, but if “it’s faster” is the reason you want to, you will almost certainly be wasting your time. Apache performs excellently when properly tuned. -jdw

    Comment by Simon Chester — April 6, 2010 #

14. Can I host mysql in the pool and have my webserver (also in the pool) talk to each other?

    Pool-hosted web servers can talk to our regular MySQL offerings. It is not possible to run MySQL inside the pool, as it does not meet the port 80 requirement. -jdw

    Comment by tech_interview — April 6, 2010 #

15. Any sniff of SSL on Pools at all? I’m looking at CoSign and wondering how possible this would be in a Pool (I know it wouldn’t work in your current infrastructure).

    Comment by Chris — April 6, 2010 #

16. Does tje port 80 only probably mean tha we also cannot run processes on high ports? That would rule out Cherokee which I would like run for its nice web dmin (runs on 9090 by default).

    It would be really seufl if fastcgi works well.

    This probably does solve my problem which as to find some web.py hosting, atlhough my app uses postgres and I am not sre how much work there would be to move it to MySQL (probably not much – its fairly simple).

    Comment by Graeme — April 7, 2010 #

17. If the process that binds to port 80 also binds to a high port, it will succeed, but you won’t be able to connect to them from outside our network. You could theoretically reach it from another pool, lane or the ssh server though, which could be useful for some sort of backchannel communication/administration.

    Slap a big red “unsupported” sticker on that last sentence though.

    -jdw

    Comment by jdw — April 7, 2010 #

18. Will pools support PHP op-code caching (XCache, APC etc.)? We use the Symfony framework which needs this to perform well.

    Also, any chance of having a per-pool Memcache service?

    Comment by Nick — April 8, 2010 #

19. Nick-

    APC is known to work. I’m not sure if it’s included in the pool distribution though, so if you set one up and can’t find it, just let us know and we’ll get it copied in there. I have no experience with XCache, but if you want to build it and load it in, it’d probably work fine.

    But, this is eerie… When your comment came in I was actually sitting here at that exact moment evaluating the feasibility of per-pool memcached.

    The answer is yes, we are definitely going to make that an option.

    -jdw

    Comment by jdw — April 8, 2010 #

20. Awesome@Memcache support!

    I see you when you’re sleeping. I know when you’re awake.

    St. Nick

    Comment by Nick — April 8, 2010 #

21. Would there be any chance of getting mod_rails (aka Phusion Passenger) and Ruby enterprise edition in a Pool?

    Also, can you please clarify the pricing of a 128MB pool?

    “The base price for a pool is $3.43/month.”

    vs.

    “Pools can be configured at any memory size you desire between a minimum of 128MiB ($6.11/month)”

    Thanks!

    Comment by Greg — April 8, 2010 #

22. mod_rails should definitely work, and we’re likely to provide it for pools alongside mod_php and mod_wsgi soon. I don’t know enough about Ruby enterprise edition to comment there, but don’t think there’s a FreeBSD port for it, so you’d have to build it yourself.

    The current monthly pool price is the base price ($3.43) plus the RAM price ($21.45/GiB). So for a 128 MiB pool, it’s:

    $3.43 + (128 MiB * $21.45 / 1024 MiB)) = $6.11

    We’ll be including a calculator with the public site documentation, because it’s one of those things that becomes obvious as soon as you play around with it.

    -jdw

    Comment by jdw — April 8, 2010 #

23. Could you explain the difference in performance between pools and a regular non-pool site is? My main interest is in PHP/MySQL sites that run off wordpress. Would I notice a difference in speed even in low-traffic sites or only in high traffic sites? If only high traffic, what sorts of bandwidth/hits are we talking to see a difference?

    Performance difference depends largely on the type of application, not so much traffic level. “Heavyweight” frameworks (e.g. Django, Catalyst, Zend, Rails) and PHP apps that don’t run in safe_mode are the largest performance beneficiaries of pools. WordPress works fine with the PHP 5 Fast setup, so would only really be a pool candidate at extremely high traffic levels or if you don’t want to hassle with safe_mode restrictions. -jdw

    Comment by Flav — April 13, 2010 #

24. Just wondering, but would this be a way to get some form of SSL?

    I know you say “port 80 only”, but for, say, a private/limited-use site there’s nothing really stopping one from serving SSL on 80 instead of 443, right?

    Perhaps something like stunnel as a front-end to an existing site?

    No, you would not be able to run HTTPS on port 80. -jdw

    Comment by Rob — April 17, 2010 #

25. That’s a great feature addition for NFS.net. Good work guys.

    Question: Is it possible for us “poor” and low-budget web admins to be able to run a one-time Pool test for a short period eg. 15 days without costing us the expense of 3-5 months for our sites that run now? I’m asking because I would be interested to know how my two Drupal web sites running here would perform on the same pool, running in different lanes. Would you consider such an option?

    Thanks.

    No. Pools, like the rest of our services, are priced based on the cost of providing them. -jdw

    Comment by Vasilis — April 18, 2010 #

26. Very awesome feature, I’m considering trying a few VPS apps out to see if they’ll work. Linode is fun and great, but more and more I’m getting less time to do server maintenance myself and just want to focus on the apps.

    Is there any sort of support for cron jobs? For instance, let’s say I have a search server (sphinx) in one lane and apache in another. Is it possible to have a) apache communicate with the other lane (I’m assuming only on port 80) and b) for a cron in the search server to index items in the mysql process every 5 minutes?

    You guys are beautiful, I love you all.

    Yes, cron job support will come to pools first because lanes provide what we currently lack: a context within which to run the job. -jdw

    Comment by andrew — April 19, 2010 #

27. I’m trying to understand how exactly is this going to work.

    So, basically, from what I understood there will be an SSH environment to where we can SSH to (like with the current shared hosting) and the file system contents will be mirrored to the “pool servers”. Is this correct?

    I guess I’m really just trying to figure out the deployment scenario for a modern Perl application (with several dependencies such as Catalyst) by locally installing modules instead of asking for module installs using support requests every time.

    Pool site maintenance doesn’t differ much from our regular hosting in this regard, with the sole exception that you have access to the config files for your server process. -jdw

    Comment by Nilson — April 22, 2010 #

Sorry, the comment form is closed at this time.