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

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.

24 Comments

RSS feed for comments on this post.

1. You fucking rock.

   Comment by micio — September 24, 2014 #

2. Well, then. It would appear that I’ve found my MongoDB database’s permanent home.

   Comment by Pikadude No. 1 — September 25, 2014 #

3. You guys are awesome!

   One question: Does this mean that, in principle, you support Websockets as well?

   My use case scenario would be the following: There are several web server implementations in Haskell that accept requests which desire to upgrade the TCP connection of the HTTP request and switch to the WebSocket protocol. With the new persistent processes that you’ve implemented, I can now run one of these custom web servers. Now, the question is: do you allow the HTTP request to become a persistent TCP connection as well?

   Websockets, or any kind of persistent connection are dangerously close to a VPS, of course.

   Comment by apfelmus — September 25, 2014 #

4. We do not support WebSockets at this time; here, web services means HTTP. At their core, the purpose of WebSockets is to reinvent the Internet over port 80 TCP, and we do not currently believe that’s a good idea. -jdw

   Comment by jdw — September 25, 2014 #

5. I read this post with considerable interest. It’s well-written. I think I most appreciate the resource-tracking improvements myself although the addition of persistent processes will doubtless prove the greater attraction for many!

   BTW, the word “care” or whatever else was intended seems missing from the passage “takes of them” that appears in the second paragraph.

   Fixed, thanks. -jdw

   Comment by bumpylight — September 25, 2014 #

6. Fair enough. 🙂

   So, just to clarify, you currently stick to regular HTTP GET / POST / etc requests, and don’t support “push notifications” or anything where the server keeps a persistent connection to the client. Only the client may request data from the server (via HTTP), not the other way round.

   For instance, if I wanted to implement a web chat application and host it with NFS.NET, the client implementation would have to issue GET requests in regular intervals to fetch the most recent messages.

   Is that a good way to put the use cases you intend to support at the moment?

   Comment by apfelmus — September 25, 2014 #

7. We support HTTP. If you want to have a client open an async GET/POST request and have the server stall the connection until it has something to tell the client, that’s totally fine. Just make sure you use an evented backend that can handle a larger number of open connections with low overhead, like NodeJS. -jdw

   Comment by jdw — September 25, 2014 #

8. Thanks a lot!

   Comment by apfelmus — September 25, 2014 #

9. Oh my. This is *huge* for NFSN!

   Congrats, JDW & co.

   I’m having gleeful thoughts about what the future holds here, and can’t wait to see if I can bring a few outside pets in-house. 🙂

   Comment by Pat — September 26, 2014 #

10. I want to vote you into congress! Thanks so much for your excellent service.

    Comment by Porter — September 26, 2014 #

11. Congress? Gosh, there’s no need to get nasty. Nobody deserves that. 😉 -jdw

    Comment by jdw — September 26, 2014 #

12. You all have been my lifeline for six years. This sort of dedication for the user and the administrator experience is what keeps me here. Keep on rockin’!

    Comment by UMJeremy — September 26, 2014 #

13. Thank you for the RAUs discount. You truly are a jewel among web hosts!

    Comment by jandm — September 27, 2014 #

14. Is mono available in any realm or is there any other way to run C# apps? Assuming the program can host FCGI of course.

    Comment by T3h Ub3r K1tten — September 28, 2014 #

15. You might have to ask for it since it hasn’t been super-useful before now, but it definitely ought to be possible.

    -jdw

    Comment by jdw — September 28, 2014 #

16. Very interesting! I wonder if it’d be possible to have a daemon using long polling in the backend (or whether that would interact badly with the other layers).

    Comment by kbuck — October 1, 2014 #

17. great work, might add persistent connections and do ajax now 😀

    keep being awesome, never end up like google.

    Comment by smellymoo — October 11, 2014 #

18. Thanks for improving the service and reducing the costs. Definitely sets y’all apart in the morass of hosting businesses.

    Comment by eli — October 15, 2014 #

19. You guys are wonderful. I feel some daemon summoning going on in my future. Any news on when this is coming out of Beta?

    Comment by willr — October 16, 2014 #

20. The beta is only to gate signups, we consider the actual service production quality. If you really want to wait, it won’t be long. -jdw

    Comment by jdw — October 16, 2014 #

21. Could I run a Docker container as persistent process?

    Comment by Tom Davies — October 21, 2014 #

22. Not at this time. Although there are some similarities between our persistent process system and Docker, the two are not compatible. -jdw

    Comment by jdw — October 21, 2014 #

23. Oh boy, I can’t wait to see how Django performs here! VPSes begone, if it does well! But, part of an issue will be installing various python libraries and/or using virtualenvs. Some of those libraries requires a build toolchain, etc.

    Comment by GM — October 31, 2014 #

24. Would like to add my thank you to the chorus.

    Comment by Karim Sumun — November 4, 2014 #

Sorry, the comment form is closed at this time.