Beta – NearlyFreeSpeech.NET Blog

Unlimited free bandwidth!* (*Some limitations apply.)

jdw — Fri, 19 Feb 2016 00:36:41 +0000

We’ve been hard at work behind the scenes developing the next-generation of our core hosting technology, and we’re ready to move it to public testing. It has some exciting new features:

TLS enhancements
HTTP/2 support
Automatic gzip compression
Major Access Control List (ACL) improvements
Shared IP blacklist support
Websockets support
Wildcard alias support

To encourage people to help us test out the new stuff, we’re exempting participating HTTP requests from bandwidth charges for the duration of the test. You can opt-in to the test for a particular site by selecting the “Use Free Beta Bandwidth” action on the Site Information panel for that site in our member interface. That page has all the fine print about the test, which mostly cover two central points:

Reminding people that it is a test and things might not work.
Clarifying that although there is no fixed limit to the amount of bandwidth a site can use under this test, there is a “floating” limit: don’t cause problems.

This test (and the free bandwidth) will run through at least March 15th, 2016.

Below, we’ll also discuss each new feature briefly.

TLS enhancements

The major enhancement to TLS (transport layer security, the technology that makes http:// URLs into https:// URLs) has to do with scalability. As people may know, we currently use Apache as a front-end TLS processor. As a test, we generated test keys and certificates for every site we host and loaded them all into a single Apache config just to see what would happen. The resulting server process took nine minutes to start and consumed over 32 GiB of RAM before answering its first request. That’s… not going to work. So we’ve written a great deal of custom code to solve that problem.

We’ve also always been worried that the overhead of TLS would require us to charge more for using it. One side-effect of this work is that we’ve reduced the fixed resources required to support TLS so much that we can now definitively say that that won’t be an issue.

The new system also improves the performance of TLS requests, and made a couple of other changes we were able to backport to the existing setup. First, we’ve eliminated TLS as a single point of failure. Second, due to our use of Apache as a TLS frontend, the last hop of an HTTPS request is handled as unsecured HTTP on our local LAN. Although the probability of anyone monitoring our local LAN without our knowledge is pretty small, in a post-Snowden world one has to acknowledge that taking reasonable precautions against improbable things isn’t as paranoid as it used to be. So last-hop HTTP traffic (all last-hop HTTP traffic, not just HTTPS) is now secured with IPSEC while it is on our LAN.

We’ll have more to say about TLS in the near future.

HTTP/2

RFC 2616 established HTTP/1.1 way back in 1999. It took many years for it to get properly adopted. Since then, there have been many attempts to improve it, like SPDY. In the end, RFC 7540 laid out HTTP/2 as the official successor, bringing many of the advantages of SPDY and similar protocols, and a lot of combined wisdom and experience to the new protocol.

Our beta service supports HTTP/2 right now.

In order to take advantage of it with a web browser, you need TLS configured. HTTP/2 can work over unencrypted connections, and although we do support that, no browser does. The default for the future of web browsing is intended to be encryption.

Automatic gzip compression

Contrary to popular belief, we’ve supported gzip encoding for a long time. The problem historically was that getting there has been a bit too tedious for most people. Delivering gzip-encoded static content requires maintaining two copies (regular and compressed) and twiddling around in .htaccess. Dynamic content is much easier; we’ve actually enabled gzip encoding for PHP by default since PHP 5.5. But still the word on the street is that we don’t have it, because when people think compression, they think mod_deflate.

We’ve never supported mod_deflate because it’s one of those solutions that is simultaneously easy and terrible. With mod_deflate, if someone requests a piece of static content and says they support gzip encoding, the server compresses the content and sends it to them. If another person requests the same content and says they support gzip encoding, the server compresses the same content again the same way, and sends it to them. Over and over, performing the same compression on the same input every time, wasting lots of resources and hurting the throughput of the server. (In testing, we found it was not unusual for requests handled this way to take longer than if no compression was used, even though the overall size is smaller.) Easy. And terrible.

Our beta service is capable of fully automatic gzip encoding of any compressible content. If someone requests a piece of static content and says they support gzip encoding, our system compresses the content and sends it to them. And then it stuffs it in a cache, so when the next person requests the same content with compression, it’s already ready to go.

Major Access Control List (ACL) improvements

ACLs (currently called IP access control in our UI) are how you decide who is or isn’t allowed on your site. People use them to block spammers and bandwidth leeches, or to limit access to their home network while a site is being developed.

First and foremost, the performance of ACLs has been dramatically improved with the new software. We greatly underestimated the degree to which some people would get carried away with ACLs. The site on our network with the largest ACL currently has over 4000 entries. That takes a lot of processing and really slows down access to that site. We could argue that such a large ACL is fundamentally unreasonable and that if using it has a performance impact, so be it. Or we could make the new system capable of processing an incoming request against that site’s ACL in 3 microseconds. We chose the latter.

At the same time, we’ve also dramatically expanded what can be included in an ACL. It’s now possible to filter inbound requests based not only on IP address (now including both IPv4 and IPv6) but also on protocol (http or https), request method (GET, POST, etc.), and URL prefix. So, as a purely hypothetical example that I’m sure won’t be of any practical interest, an ACL can now be used to block POST requests to a WordPress blog’s login script if they don’t originate from specific IP’s you know are OK without interfering with public access to the rest of the site.

Shared IP blacklists

We’ve also added the ability to filter incoming requests against a sort of giant shared ACL, a list of IPs flagged for bad behavior.

We haven’t turned this on yet, because we’d really like to include Project Honeypot’s http:bl in the list, but we’d need their cooperation to set that up, and they haven’t gotten back to us yet.

We can’t guarantee this will be effective, attacks tend to adapt and some botnets are huge, but we’re committed to finding new and better ways to keep our members’ sites safe.

Regardless of how the details shake out, this feature will be opt-in. At some point in the distant future, well after this test is over, if the shared list works really well and causes few problems, we may eventually make it the default for new sites. We’ll wait a long while on that, and then make the right decision at that time.

Websockets support

Websockets are a way to convert a web request into an efficient bidirectional pipe between a web browser and a server. They’re super handy for high-performance and interactive apps. They were very high on the list of things there was absolutely no way our infrastructure could ever support. Yesterday.

When things settle down, we’ll try to do a brief tutorial showing how to use them.

Wildcard aliases

Wildcard aliases refers to the ability to add an alias like *.example.org to your site and have all traffic for whatever name people enter (e.g. www.example.org, an.example.org, another.example.org, whatever.example.org, perfect.example.org, etc.) wind up on that site.

We’ve never supported wildcard aliases because they’re not super-common (in most cases, example.org/perfect is just as good as perfect.example.org) and because our existing system uses a hash table to speed up alias lookups; you can’t hash wildcards. The new system removes this limitation without sacrificing performance. We still don’t recommend using them unless you have a specific need, but there are a couple of use cases where there’s just no substitute. (One site which is perhaps not surprisingly no longer hosted here had 6000 aliases at the time it was deleted. That same site today could have gotten by with one wildcard alias.)

The “specific beats general” rule applies to wildcard aliases. If the site example has the alias www.example.org and the site wild-example has the alias *.example.org, requests for www.example.org will go to example not wild-example.

A caveat

Although these features now exist with the beta service, most of them aren’t reflected in the UI yet (where applicable). It seemed cruel to provide an interface to set up cool functionality that wasn’t actually available.

Now that it is, we’ll be rectifying that over the coming weeks as we refine and troubleshoot everything. In the meantime, if you want early access to one of the features listed here that requires custom configuration and you’re a subscription member, just drop us a line through our site and we’ll see what we can do.

Last words

This is at once very exciting and very daunting. The software being replaced is 15 years old and showing its age; the new features we’re bringing out are fantastic (and, in some cases, long overdue) and we couldn’t have done them with the old architecture. But on the other hand, the old software is a legitimate tough guy. It’s handled tens of billions of web requests. It built our business from nothing. We know exactly what it does under a dozen different types of DDOS attack. And here we are, replacing it.

There is absolutely, positively no way the new software is as bug-free or battle-tested as the old stuff. The latest bug logged against the existing software was a memory leak in 2009. The latest bug against the new software was fixed less than 24 hours ago. There will be problems. (Which we’ll fix.) Then there will be more problems. (Which we’ll fix.) It will inevitably crash at the worst possible time at least once. (Which we’ll fix.) And, there will no doubt be something obscure that works great on the current system but which doesn’t work on the new one that we won’t be able to fix. (But not to worry, we’ll be keeping the old one around for quite awhile.)

So this is a daunting move for us, but we’ve never made decisions based on fear and we’re not going to start now. So it’s time to push this technology out of the lab and onto the street so it can get started on its five hundred fights.

Please help us out and opt as many sites as you can into the beta, so we can test against the broadest possible cross-section of traffic and types of site content. Every little bit helps!

Thanks for your time, help, and support!

More power, more control, more insight, less cost.

jdw — Wed, 24 Sep 2014 19:51:35 +0000

We’ve made some very big changes to the fundamental nature of our service. We now support persistent processes and delegating requests for your site to those processes using HTTP, SCGI, or FastCGI. We’ve added the ability to graph up to two weeks of your site’s resource usage. And we’ve slashed resource charges by almost 70%.

More power & more control.

Ever since we started, one of the inviolable limitations of our service is that we don’t let you run your own persistent processes. No more! Using the technology underpinning our NFGI PHP implementation, we’ve added support for configuring and controlling persistent processes from our member interface. These processes run as part of your web site, and when you’re not around, our system takes care of them. For example, it keeps an eye on them and can restart them if they exit.

There are two main uses for this feature.

First, although we support a huge variety of languages for web development, unless your favorite language is spelled PHP then you were stuck running it as a CGI script. For any kind of modern web framework, that causes some substantial performance problems. Ruby on Rails, Django, Catalyst, Node.JS, Network.Wai? Sure, technically you can run them here, but it’s not what you’d call a good idea.

Take that long-standing well-known fact about our service, and pitch it straight into the trash. We’ve built a new server type that can delegate incoming requests to the web application server of your choice running as a persistent process. This currently supports HTTP, FastCGI, or SCGI. (Although it’s not clear that anyone actually uses SCGI.) You can even mix-and-match technologies on different paths of the same site. Or with HTTP, you have the option to take advantage of our Apache-based infrastructure or to bypass it entirely for maximum speed and control. (Either way our edge network will still have your back, accelerating static content and protecting you from a variety of web ne’er-do-wells, so you can focus on your app.)

Second, there’s no requirement that your persistent process be a web app. Although nothing but web apps will be accessible from outside our network, from inside our network, you have a lot more flexibility. Want a private memcached instance to turbocharge your site? You got it. Redis? Check. PostgreSQL? Now possible.

This feature is going to go through a very brief open beta period for a couple of weeks; we want a bit of a slow start because trying to anticipate all the creative things our members will do is simply impossible, so we want to keep a close eye on the first handful of setups to see if anything needs tweaking.

During the beta, persistent processes will only be available on the proxy site type. If that’s not what you need, but you still want to try this out, you can always set up a process on a proxy site and talk to it from another site hosted here. Or you can just set up PHP-FPM.

~~To get in on this now, just log in to our member interface and submit an assistance request. We’ll convert the site(s) of your choice and you can take it from there;~~ These features are fully implemented and integrated into the UI. Just start by setting the server type of your site to “Custom” or “Apache 2.4 Generic” and the Proxy and Daemon management options will appear on the Site Information Panel.

As this comes out of beta, watch our blog for a series of tutorial articles demonstrating how to use this feature in conjunction with various technologies.

Although it might seem like it at first glance, this does not turn our service into a VPS. We (still) have no interest in going down that road. This feature is immensely powerful, but it doesn’t include root access and can’t make anything but web services available over the Internet. If you want to run an email server, voice chat server, or game server, you’ll still need a VPS for that.

This is designed as an alternative for people running web sites who might have felt forced to move to a VPS or dedicated server in the past to get more flexibility (at the cost of all the 24×7 administrative headaches that come with it). Like all of our services, it’s pay-as-you-go and fully managed, which means that we’re the ones keeping all that infrastructure up-to-date, secure, tuned, and running. You just do what you do. We’ll take care of the rest.

More insight.

One of our most common requests that has always had a technical barrier is getting you better visibility into the resource usage of your site. We’ve now been able to add an interactive Javascript chart that shows up to two weeks of RAM & CPU usage for most currently-supported server types (all the Apache 2.4 + PHP site types and the new proxy-based server type).

As part of this change, we’ve introduced a new internal tracking system that can take resource measurements on a per-site basis for a bazillion tiny sites without collapsing under its own weight. Naturally we’ve applied that directly to our resource-based billing. So if the random sampling element of our resource billing made you uncomfortable, just make sure your site is using one of the above types, and your usage will be calculated using the new, deterministic method.

In the future, we hope to expand on this functionality to gather and report more statistics about your site that will help you explore and optimize your site’s resource usage.

Less cost.

Our resource-based billing has been a huge success. Between the economies of scale associated with the popularity of this model and the slow decline in the cost of hardware, we’ve been able to greatly reduce what we charge for resources. The cost of a resource accounting unit (RAU) has dropped from 3.25 RAUs = $0.01 to 10.59 RAUs = $0.01. That’s almost a 70% drop. You don’t need to do anything to take advantage of this; it’s automatically applied to all resource-billed sites. This change means that over 2/3rds of resource-billed dynamic sites (and well over 99% of static sites) now pay less than $0.01/day for their resource usage.

These are all great changes. They will make more power available to more people for less money. But these changes are all steppingstones. Each one can be improved, extended, enhanced. And that’s not all. We’ll have more good stuff for you in the coming months. But now, we get to my favorite part, where we hand this stuff to our members and see the amazing things they’ll do with it.

Updated 2014-11-16: The daemon and proxy features went out of beta a few weeks ago with almost no fanfare. We’ve updated this entry to reflect the non-beta setup process; also be sure to check out the first in our how-to series about these features, which covers Django.

IPv6, SSL, scheduled tasks, storage discounts & bulk bandwidth

jdw — Wed, 26 Dec 2012 05:23:59 +0000

We have quite a few feature announcements to bring you this holiday season. We’ve added support for several features, some of which have been requested for years like IPv6, SSL, and scheduled tasks (AKA cron jobs). We’ve also introduced new billing options that make our service pricing fairer and more scalable; these options will help a broad variety of our members save money.

IPv6 support for hosted sites

We’ve added IPv6 support for hosted sites. Just select the “Manage IPv6” action from the site info panel and enable it. Each site that enables IPv6 is currently assigned a unique IPv6 address. There is no extra cost for IPv6.

IPv6 isn’t fully deployed on the Internet yet, and consumer ISPs are the worst laggards, so IPv6 isn’t enabled by default and you may want to consider whether it’s right for you. More info is available in our UI.

SSL support

We always said that we would focus on SSL support as soon as IPv6 was done. And that’s just what we did. SSL support is now available in two forms.

First, you can obtain (or generate) an SSL certificate for any alias on your site, upload the certificate, the key, and the chain file (if applicable) to your site, and then request SSL be enabled for that alias through our UI. This is a great option if you want to secure traffic to your site for all visitors.

Second, generic support for securing the (shortname).nfshost.com alias of each site is available without the need for your own certificate. Use of this option is also requested through our UI, but it’s our domain name, so its use is subject to our pre-approval. (For example, we won’t be approving any sites with names like “securebanklogin.”) This option is good if you just want to administer your site through a web UI securely.

Our SSL implementation depends on the SNI feature of the TLS standard, which is now available in all modern browsers, so we are comfortable deploying it. SSL currently does not have any extra cost associated while it retains experimental status. It may get a nominal fee in the future to cover the added CPU cost of encryption once we get a better idea about how tightly we can pack certificates without causing problems.

Scheduled tasks

We’ve added the long-requested ability to run scheduled tasks on specific sites at regular intervals. Great for processing log files or refreshing content, scheduled tasks can be set to run hourly, daily, weekly, or monthly. There’s currently no extra charge for this feature, but we’ll keep an eye on the resources it uses.

Storage discounts and resource-based billing

Most people (including us) will acknowledge that for a long time, the greatest flaw of our service is that it bills a large amount of the cost based on how much disk space a site uses. This charge then pays for all the CPU and RAM it takes to host sites. This works well enough in terms of covering our costs, but forces sites that are very large to subsidize sites that are very small but resource-intensive. That’s not fair, so we’ve made two changes.

First, we’ve cut the storage charge for static sites, which by definition use few resources. Our published rate is $0.01 per megabyte per month, but with this change, static sites are now charged at $0.01 per 5 megabytes per month. That’s an automatic across-the-board 80% cut for all static sites.

Second, we’ve introduced a new option for dynamic sites called “stochastic billing.” If selected, this option cuts the storage costs for dynamic sites by 90% to $0.01 per 10 megabytes per month. In its place, it divides sites into groups and once per minute, selects a web request at random and bills the associated site for the resource usage attributed to that group. The likelihood of a given request being selected is proportional to the resources it uses, so over time the random sample converges to a very accurate representation of which sites are using which resources, and everyone who participates is billed fairly for the share of resources they used with a very high degree of accuracy.

We’ve set the pricing for stochastic billing in such a way that if everybody switched tomorrow, our bottom line wouldn’t change at all, so this is not a price increase. Most people will actually pay less. Sites that use above-average resources — the ones subsidized under the current plan by sites that use tons of disk space — will naturally cost more if they switch over. But we don’t plan to force anyone to switch. Instead, we intend to preserve both options and allocate to each the hardware resources it is paying for. Over the long term, we expect resource-heavy sites on the old plan will find fewer and fewer disk-heavy sites willing to subsidize them, which may lead them to resource shortages way down the road if they choose not to migrate and pay their own way. But we don’t anticipate any dramatic changes in the short term.

More information about this is available in our FAQ and our forum, and the option is available by changing your site’s server type in our member UI.

In the coming days, we’ll be adding a $0.01/10MiB/month + stochastic billing option for static sites as well. That’ll be better than the $0.01/5MiB/month plan for most but not all static sites, and we understand some people won’t want anything to do with a billing scheme with a random element, so it will be optional.

Bulk bandwidth option

One of the things we do that’s a little unusual is that we demand very high quality bandwidth for our member sites; there are a number of lower-priced providers commonly used by web hosts for connectivity that we don’t consider good enough. A consequence of this is that the bandwidth costs we pay are relatively expensive compared to some of our competitors of a similar size, and of course we pass that along. We feel it’s well worth it.

At the same time, we have wound up connecting to cheaper providers from time to time. This is not to serve member sites, but rather because cheaper providers — combined with clever routing and network management — can be a good way for us to soak off huge surges of incoming traffic associated with DDOS attacks without affecting the rest of our network. However, even though the bandwidth offered by these providers is relatively cheap, DDOS attacks consume a lot of it, and the more of it we have, the more resilient we are, so the overall bill is not trivial. And at the same time, DDOS attacks generate only inbound traffic, so we’re only using the inbound half of those connections (and then only when we’re being attacked).

So, we’ve got a bunch of unused outbound capacity. We’ve made the decision internally that the price/quality tradeoff is not worth using those connections for our regular traffic, but we respect that not everyone’s site is the same and that in light of the pretty significant cost difference, some people might prefer to make that decision for themselves.

As a result, we’re offering a new class of “bulk” bandwidth that will use our excess outbound capacity on a per-site basis. Instead of being priced per byte transferred like our regular offering, bulk bandwidth is priced per megabit per second (Mbps) per month. You select the amount you want and then pay $5.00/Mbps/mo. (But like most of the rest of our services, it is charged one penny at a time and can be added or removed at any time.) Your actual usage is unmetered. It’s also burst-able, meaning it groups sites together and if another site in the group isn’t using its share at any given moment, your site can borrow it at no extra charge.

Bulk bandwidth is typically best suited to sites that steadily use a lot of bandwidth, for example to distribute large files to the general public. Our regular bandwidth plan will still generally provide higher per-connection speeds, better routing and resiliency, and probably slightly better latency.

To determine if bulk bandwidth is right for a site, first figure out if it’s currently spending less than $5.00/mo on bandwidth under our standard plan. If it is, bulk bandwidth is a bad deal: pay more, get less. But if a site’s bandwidth costs more than $5.00/mo, the answer is maybe. Next, you would look at the nature of the site. If the priority is to deliver the most overall bandwidth per dollar, then bulk bandwidth might be a good choice. If the priority is to provide the fastest individual downloads, or if the site has significant interactive elements — particularly stuff like AJAX — it’s better to stick with the standard plan.

In short, the bulk bandwidth option is the freight truck to our standard plan’s sportscar. Both can move a lot of data very quickly, but in very different ways.

Final thoughts

Whew. Densest. Blog post. Ever.

If you follow our Twitter feed, you already know about these updates. But judging by the follower numbers, most people don’t, so we thought we’d mention it.

We think these changes are huge. They address a lot of the pain points that many of our members have been feeling for a long time, both in terms of features and cost. And they represent a mountain of work, especially these past few weeks to carry them over the finish line in time for Christmas.

Going forward, the biggest question will probably be about PHP 5.4. That’s the big one we weren’t able to make happen in time for this announcement. It remains available in Flex mode if you select the 2011Q4 realm, but 5.4 removes safe_mode support and hence there won’t be a “PHP 5.4 Fast.” Instead, “PHP 5.4 Full” is coming, which combines a lot of the best features of Flex (consistent paths, ability to execute external programs) with performance comparable to existing Fast sites. That’s our top feature development priority, and we’re keeping a close eye on the March 2013 timeframe that the PHP developers have announced for phasing out non-critical updates to PHP 5.3, but we can’t offer an ETA at this time. We also have some internal maintenance to do to keep things running smoothly and fix bugs.

Thanks everyone! We never lose sight that our incredible members make our service not just possible but everything it is. (And I allow myself a bit of a smug grin, secure in the knowledge that we have the hands-down smartest member base of any web host, which is the only reason we have the courage to do something as exotic as stochastic billing.)

(Updated 2012-12-26 to reflect that *.nfshost.com no longer uses a self-signed certificate for SSL.)

Pools: Arbitrary HTTP Servers, Resource Reservation and Scalability

jdw — Sat, 03 Apr 2010 11:05:31 +0000

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.

MySQL FreeBSD 7 ZFS Beta update & MySQL upgrades

jdw — Mon, 29 Sep 2008 05:28:20 +0000

Some time ago, we announced a beta test of MySQL running on FreeBSD 7 using the experimental ZFS filesystem. We’ve now concluded that beta test, and I wanted to let you know the results.

Here’s the executive summary: FreeBSD 7 is, by and large, great for us and we will be aggressively deploying it throughout our network in the near future. ZFS is also great, but while it definitely has a future on our network someday, this is not that day.

FreeBSD 7 offers significant benefits for SMP scalability, which is pretty important to us since most MySQL processes and member sites run on eight-core servers. The performance benefits on MySQL are very real, particularly on CPU-intensive workloads (which tend to be common if your tables are indexed properly). The performance benefits for member sites are less pronounced for some pretty complicated reasons, but they’re still there and they’re still worth pursuing.

ZFS is a really neat technology. By and large, it works pretty well. It’s not a great match for a MySQL server, though, since it seems to want a lot of CPU and RAM at the same time MySQL wants lots of CPU and RAM, because it works hard when asked for data and MySQL asks for data when it’s working hard. Thus, we noticed a little bit of contention and we were concerned about what would happen in low memory conditions, such as if a bunch of MySQL processes happened to surge busily at once. ZFS seems best suited to sticking on super-tightly controlled file servers that have gigs of RAM free and don’t do anything else. Even so, we’re not 100% sold on its stability, so we’ll revisit it sometime in the future and do further testing before we start loading it up on mission-critical file servers.

All of our MySQL FreeBSD 7 ZFS beta volunteers have been migrated to production FreeBSD 7 (non-ZFS) MySQL servers. They’re just the vanguard, though; we will be aggressively upgrading almost all member MySQL processes over the next few days.

The actual process is a bit complicated, but here are the essentials: we’ve brought some new hardware online running the target environment (FreeBSD 7, MySQL 5.0.67). Call that “Server A.” We’ve moved all the MySQL processes from Server B (one of the older ones) onto server A. Then, we reinstall Server B. Then we move everyone on Server C to Server B and reinstall server C. And so on, down the line.

The upgrade requires no action on your part and entails MySQL downtime averaging less than five minutes; a significant percentage of our MySQL-using members will notice only one to two minutes of disruption, if they notice it at all. Even so, we’re limiting it to low-usage periods (certain times during weekends, late nights, and early mornings). Due to the number of processes being upgraded and our need to schedule upgrades based on specific server assignments, we will not be able to coordinate individual process upgrades.

We do still have some longtime members hanging around on MySQL 4.1 running on FreeBSD 4. Since MySQL 4.1 to MySQL 5.0 isn’t always a seamless migration, we’ll be contacting those affected to let them know their situation and try to coordinate their journey out of the stone age before we do anything there.

If you want to see what version of FreeBSD or MySQL is powering your MySQL process, you can use the SQL command “SHOW GLOBAL VARIABLES” and look at the “version” and “version_compile_os” variables, or access them in queries as “SELECT @@version” or “SELECT @@version_compile_os.” The former shows the MySQL server version (which is also displayed in phpMyAdmin and by the MySQL command line client), and the latter shows the OS version: “portbld-freebsd6.3” for FreeBSD 6.3 and “portbld-freebsd7.0” for FreeBSD 7.0.

We also have a significant RAM and CPU power upgrade planned for MySQL once this upgrade is complete. That will require a brief off-hours downtime for some MySQL processes, which we will schedule and announce at a future time.

Finally, though MySQL processes will never be able to flit around our network the way web requests do, we are taking baby steps in the direction of SAN-based MySQL storage in order to decrease the lock-tight correlation between MySQL processes and specific frontend hardware.

Experimental FreeBSD 7 + ZFS + MySQL technology trial

jdw — Mon, 12 May 2008 17:40:07 +0000

For most of our production servers, we run FreeBSD 6.3, which is a well-tested, stable, and excellent-performing release. However, the FreeBSD world moves on and FreeBSD 7.0 was released earlier this year. The primary benefit to the new version is supposed to be vastly improved performance, ranging from 350% to 1500% faster, under heavy workloads.

Hey, we have some heavy workloads…

However, as longtime members may know, when confronted with a choice between stability and performance, we tend to choose stability. In fact, that preference led us to skip FreeBSD 5 entirely while the FreeBSD team tirelessly worked out the changes needed to support modern SMP hardware. (I look back to the FreeBSD 4 days when we had to use single-core systems and I whimper.)

Another flagship technology in FreeBSD 7 is ZFS. The primary benefits of ZFS wouldn’t accrue directly to our members (although it might provide the underpinnings for some neat stuff), but rather it would make our lives a lot easier. The problem with that is that there’s some debate on whether or not ZFS is ready for prime-time usage. So far, it’s tested pretty well and we’ve done some fairly abusive things to it.

Even so, odds are that FreeBSD 7.0 will never see production in our web cluster; we will most likely give serious consideration to 7.1 or 7.2, depending on the results of our internal testing. That internal testing is (and has been) underway, and we’d like to offer the adventurous a chance to participate.

Putting FreeBSD 7.0 into our web cluster isn’t really a good option, because it would entail building FreeBSD 7 versions of a couple thousand software packages, CPAN modules, python eggs, and etc, and might cause problems for custom-built CGI binaries. Instead, we feel that heavy MySQL usage is most likely to show the benefits of improved SMP code in a controlled software environment.

Thus we have set up an experimental MySQL server running MySQL 5.0.51a on FreeBSD 7 with a ZFS filesystem. If you would like your MySQL process moved to this experimental server, please submit a secure support request indicating the name of your MySQL process. Migrating MySQL between servers is very fast, but it takes about 10 minutes for a moved process’s new IP address to propagate through our network.

The trade-offs should look like this:

Your MySQL process will probably be a lot faster, especially if it’s busy.
There might be an increased chance of MySQL downtime due to instability.

Naturally we won’t let stability issues get out of hand on that server. If ZFS presents a problem, we’ll blow it away and try FreeBSD 7 under UFS2, and if that’s also unstable, we’ll kill the test and try again at 7.1. We’d also move anyone back out of the test who encountered problems on request.

Give it some thought. If your MySQL process is not mission-critical and you’re interested in helping us plan the next generation of NearlyFreeSpeech.NET servers, please drop us a line.

PHP Update: Five, finally: fast and flexible!

jdw — Thu, 27 Dec 2007 02:59:35 +0000

As many of our members know, we’ve been beta-testing PHP 5 for a really long time. The PHP 5 Beta is now over; PHP 5 has become the default for new sites created on our service.

This represents the culmination of a mountain of work on our part; in order to make PHP 5 work for you, we’ve had to retool the backend of our clustering technology to support heterogenous software environments. That’s going to have all kinds of cool benefits in upcoming days, well beyond its implications for PHP.

If you’re currently running PHP 4 and you’re happy with it, don’t worry. We’re not planning to do anything drastic to you at this time, and we’ll continue to support PHP 4 as long as the developers do.

As part of the PHP 5 beta, we’ve also unified the versions of PHP 4 and PHP 5 that appear in the ssh environment, and we’ve updated the environment to detect which version your site uses and put it first in your default PATH variable. Concurrent with the update, the /usr/local/bin/php link has been switched from PHP 4 to PHP 5, but since the “php” you get when you type “php” will come straight from the version-specific directory appropriate for your site, that shouldn’t have much effect.

In case you haven’t been following the long-running PHP 5 Beta forum thread, you may not be aware that you can switch back and forth between server types on the fly, usually without downtime. (It’s remotely possible that someone else could trigger a second update right after you, which would cause your site to display “Unknown Site” for a minute or so after switching from PHP 4 to PHP 5 or vice-versa.) To switch PHP versions, all you have to do is click “Change Server Type” on the Site Information panel for your site in our member interface, select the radio button for the site type you want, click “Save Changes,” and wait around for a minute or so.

But, hmm, what’s this? There seem to be two PHP 5 server types listed on that page… “PHP 5 Fast” and “PHP 5 Flex (Beta).” What’s that all about?

Well, we just loved having PHP 5 in beta so much that we couldn’t let it go! OK, not really. Have a look at PHP 5 Flex phpinfo() output compared to PHP 5 Fast phpinfo() output. Spot any important differences?

PHP 5 Flex is a new implementation of PHP that runs inside our customized CGI environment. This means we can do fun stuff like turn off safe_mode and open_basedir. That’s right: you can now get non-safe_mode PHP at NearlyFreeSpeech.NET. Now, this has always been sort-of possible if you were willing to mess around with .htaccess, make all your PHP scripts executable and hack #!/usr/local/bin/php lines into them at the top, but when you do that, you’re running the command line version of PHP, so weird stuff sometimes happens. PHP 5 Flex, on the other hand, runs the specialized CGI version of PHP based on the same configuration we used for standard PHP 5, and it runs standard .php files unmodified. You don’t even need to make the PHP scripts executable; it just works. It also uses all the same /home-based paths you’re familiar with from the ssh command line and CGI, like /home/public.

So why would you ever not want that? Well, the answer lies in the name of the alternative, PHP 5 Fast. PHP 5 Fast is based on mod_php5, which runs significantly faster than CGI-based PHP: often three to five times faster, especially when handling lots of small requests. If you don’t need safe_mode off to get compatibility with some strange third-party application, there’s no need to take the speed hit associated with virtualizing every request. That’s why the new PHP default is PHP 5 Fast and why we recommend leaving it as-is unless you have a good reason to change it. PHP 5 Flex is also beta; there may be a few problems to kick around. If you try it and find them, let us know via the forums or support requests.

So that’s our big PHP 5 update. It’s been a long time coming and a lot of work; we hope you enjoy it!

A lot faster for a lot less money? Who wants that?

jdw — Fri, 23 Feb 2007 22:21:31 +0000

We are now officially soliciting beta testers for our new high-capacity high-volume service for static content. It has just gone live and it is not just fast, it is insanely fast. We’re talking ludicrous speed here, people! An experimental download was just clocked at 43 megabytes per second, but real-world downloads will probably be constrained by the size of off-network pipes.

Final pricing for this service has not been established, but it will be available for a small flat daily fee and with a massive discount over our current per-gigabyte pricing.

If you are a current member and you have large, static content like music, videos, or file downloads, and you use 10+ GB of bandwidth per month, you are eligible for this beta. Submit a secure support request for more information. (You’re also eligible if you use less bandwidth, but since the service is highly optimized for bulk use, so is the pricing, meaning it may increase your costs rather than decrease them. Even so, you’d still enjoy the massive speed boost.)

Dynamic content (PHP, CGI, etc.) is not eligible for this new service. However, if you can segregate your static content into a subdirectory, one site can use both services at the same time!

API New Year!

jdw — Tue, 02 Jan 2007 05:03:43 +0000

To help ring in the new year, we’ve been hard at work on a major new requested feature. (Well, several actually, but one at a time….)

We are pleased to announce that the NearlyFreeSpeech.NET API is about to enter beta. What is the NearlyFreespeech.NET API? In a nutshell, it’s a way to control your hosting services from a program or script.

The API platform we’ve created is fairly robust and very easy to use. (Here’s a shocker: it’s a web-based!) But since we’re just getting started with this, the functionality currently available is somewhat limited. However, the four most requested API functions are supported: adding and removing site aliases and email forwarding addresses.

We’ll add more functionality based on demand. Over time, we’ll also be migrating our own user interface to use the API, so someday it should be possible to use it to do pretty much anything you can do from our site, and plenty of things you can’t! (But don’t hold your breath waiting for a “increase account balance” API call. )

While we get this up to speed, beta space will be very limited, so if you want to try it out, drop us a Secure Support Request asking for your API key. You can access the API directly from the CGI or programming language of your choice, or use an example PHP class library that we’ve developed.

There’s also a documentation experiment attached to this. To document the API, we’ve created our first Wiki. We have a mountain of technical information about our service that we need to communicate to our members, and we know we need to find a better way to do that than our dauntingly-large FAQ. However, putting information out there in the form of a world-writable Wiki is a bit nerve-wracking, so we’re giving it a try with a special Wiki for the API. Check it out here. We’ll see how that goes.

Note: We are using a self-signed certificate for the api.nearlyfreespeech.net SSL site, because there are some license issues for us to explore with using a single SSL certificate on multiple servers. This means you’ll need to accept a certificate certified by an unknown authority (that’s us) to see the API site. A future version of the PHP library will include the NFSN CA certificate and use it to verify that you’re talking to the real API, but we don’t recommend importing it into your browser or anything.

As always, your feedback is welcomed and encouraged!