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.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.