On Saturday, March 29 at about 4pm US Eastern time, we rebooted one of our file servers that hosts content for member sites. It experienced a critical hardware failure and did not come back online. It took about 28 hours to get things back into service. We’re going to talk briefly about why that happened, and what we’ll be doing differently in the future.
Continue reading Post-mortem report of Saturday’s file server failure…
We’ve made a few changes lately that we want to make sure everyone knows about.
- Bandwidth pricing has been radically revamped (downward)
- Storage pricing has been slightly tweaked (downward)
- Revamped membership security settings (2-factor authentication, SMS, and more)
- New options to control how long accounts and memberships are retained.
Read on for full details.
Continue reading Price cuts, more security and recovery options…
Back in 2009, we changed our support from a “best effort” model to an experimental “pay per use” option where people purchase a block of support points and then we charge a variable number of points based loosely on how much time we spend responding to an issue.
Over the past few years, the support points model has proven wildly unpopular with virtually everyone (including us), unprofitable, and it hurts the quality of support we provide. Consequently, it must go. Effective immediately, we are replacing this model with a support subscription where people make a conscious choice about whether they want individual support or not and then either pay or don’t pay a monthly fee of $5.00 based on that choice. (If you currently have support points and prefer that system, you can keep your points as long as they last, but you won’t be able to buy more.)
We’re also making several changes to our support system to make it easier to interact with.
Continue reading Member support: points out, subscriptions in (Updated 2014-02-15)…
We’re officially introducing three new realms for CGI and ssh, not only to help us stay up to date as CGI languages evolve but also to let us better meet the needs of different members who want different, often conflicting, versions of a language, like Python 2.7 and Python 3.3.
Continue reading CGI/ssh Upgrades…
We are finally officially announcing that PHP 5.4 and PHP 5.5 are available to all members. In the past, we have offered “Fast” and “Flex” versions of PHP for people with different needs. That’s no longer the case for PHP 5.4 and beyond; we have developed and deployed new technology that is both faster and more flexible, all in one. This is a big deal for us; with this step, we’ve gone from being behind the curve on PHP to — I feel — ahead of it, and we’re well-positioned to stay there.
We’ve also rolled out Apache 2.4 for these new server types, and we have some config advice for those looking to make the switch.
Continue reading PHP 5.4, PHP 5.5, and Apache 2.4…
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.
Continue reading IPv6, SSL, scheduled tasks, storage discounts & bulk bandwidth…
Free speech is a funny thing. A lot of people are for it, as long as it’s for them. An awful lot of people lose interest in principles when someone says something they don’t like. And lots of people who say stuff use NearlyFreeSpeech.NET to do it. So it’s not in any way unusual for us to get complaints, or random demands to remove a web site. Some small fraction escalates to a sternly-worded letter from a lawyer containing such toothy admonitions as, “If you do not immediately comply and confirm to me that you have done so, I will be forced to advise my client to instruct me write to you again.” It rarely goes beyond that, because at the same time they’re writing to us, the good lawyers are explaining to their client that web hosts have federal immunity against that type of lawsuit. Some few do go ahead and threaten to sue us, either because they don’t know better or they figure maybe we don’t.
Continue reading Official UK government attempt at censorship…
We will be making two changes to our MySQL service offering, one of which will be related to the pricing of large processes, and one related to upgrading the version (and distribution) of MySQL we use.
I wanted to put the technology change first, because it’s way more interesting and affects a lot more people, but I know pricing changes always attract the most attention, so I will start there instead.
Traditionally, we have avoided charging for space used by MySQL processes. Most processes are very small, and there simply wasn’t enough usage or problems to merit hassling people for a few extra pennies. Unfortunately, that’s no longer true. We need to take steps to either rein in a few cases of excessive usage or recover enough money to cover the costs of the resources we must allocate to them. Here are some of the numbers:
- The median size of a MySQL process is about 5.2 megabytes.
- Over 90% of all MySQL processes are less than 40 megabytes in size.
- For the first time in our history, the top 5 MySQL processes are all over 10 GiB in size.
- The largest 10 (not 10%, just 10) of MySQL processes use almost 34% of the total space.
- The largest 1% of MySQL processes use almost 65% of the total space.
Something is wrong if two people are paying the same for MySQL but one is using (literally) thousands of times more than the other. And obviously we need to fix that. But we need to do that in a way that has absolutely no impact on the people (i.e. almost everybody) whose usage is both reasonable and within our expectations.
In order to ensure that we don’t negatively impact people unnecessarily, we have taken the 90th percentile size (40 megabytes) as a cut-off point. If your usage is less than that, nothing about your MySQL pricing will change based on space used. If your usage is more than that, then on September 1st, 2012, we will begin charging an additional fee of $0.002/MiB-month for MySQL storage over 40MiB per process. This will be calculated and billed exactly the same as site storage currently is, except that it is five times cheaper, and the first 40MiB of space used by each MySQL process will be exempt.
In addition, there is also a second pricing problem we need to solve, which is heavy database I/O loads. This problem frequently goes hand-in-hand with large processes, because with small ones a little inefficiency is typically too small to notice. We have noticed that occasionally some databases run into problems due to poorly-optimized queries (i.e. missing or inefficient indexes). For example, we have seen a couple of places where a site depends on a MySQL query of a large table with no indexing that results in large temporary tables being written to disk. This takes ages — a good rule of thumb is that if your query is writing temporary tables to disk, you’re doing it wrong — and so requests from that site start to pile up, and you wind up with the MySQL process trying to write the same huge temporary tables to disk 8 or 10 times at once. This is so intensive that in our shared hosting environment, other people’s processes start to suffer because disks only spin so fast and they’re starving to death waiting for their turn. Of course we act promptly when these conditions occur, and since they are almost always the result of poor optimization, they are typically easily for the member to resolve once we bring it to their attention. But occasionally we get a response like “why should I?” and unfortunately we need an answer to that question. Therefore, effective September 1st, if we determine that a process is using a disproportionate amount of I/O and the responsible member is unwilling or unable to resolve the issue, the fee for MySQL storage will apply to the whole process (no 40MiB exemption), and will be set to a higher rate as determined by us as necessary to cover the cost of resources being used. This will give us some flexibility to support larger MySQL requirements than we currently can with the current one-size-fits-all model. We will, of course, retain the option to refuse service to use cases that we find truly abusive or unsupportable on our infrastructure. Please keep in mind that this change will affect the pricing of about five MySQL processes. (Again, not 5%, just 5.) So if you’re worried that this will affect you, it almost certainly won’t, and we will contact you individually (if we haven’t already) before it does.
So, to sum up the pricing changes:
- Less than 10% of our MySQL-using members will see pricing changes.
- People who are affected are using dozens, hundreds, or thousands of times more resources than everybody else.
- Of the affected 10%, most will pay a few cents a month more and about 75% will pay less than $2.00/month more.
- MySQL processes using more than 40MiB of space will be charged $0.002/MiB-month for the excess.
- We will be able to set custom pricing for MySQL processes with unusually intense I/O needs.
- These changes will go into effect September 1st, 2012.
- This will improve MySQL performance for everybody by creating incentives not to waste resources and by allowing us to use money collected from heavy MySQL users to allocate more resources to them, so they have less effect on everyone else.
With the pricing stuff out of the way, I want to move on to the other part of the announcement. After all that, we’re getting rid of MySQL! Well, OK, sort of, but not really.
We are going to start moving from MySQL 5.0 to MariaDB 5.3. NearlyFreeSpeech has been around long enough that when we started offering MySQL, it was “owned” by its own open-source friendly company. Later in its life, it was acquired by Sun, and things started to get a little weird, leading to a number of releases that in our opinion were of very poor quality and thus we never adopted. Then, to make things worse, Sun was then acquired by Oracle. This has had a number of negative influences on us, as we have depended on both OpenSolaris and MySQL in the past. In our opinion, for a variety of reasons, Oracle is not a good entity for us to have external dependencies on. We feel their handling of the open source community has left a lot to be desired, and that their support for MySQL has continued in the wrong direction.
Fortunately, as a project with roots an open source, MySQL has options and alternatives. The one we have chosen to pursue is MariaDB. This is a fork of the MySQL project by the original creator of MySQL, Monty Widenius. It uses some of the original code, some replacement code which is much better (e.g. it uses XtraDB, a drop-in replacement for InnoDB), and has (in our opinion) better features and quality control than Oracle’s MySQL releases. This will not only improve performance, but also let people take advantage of a lot of newer MySQL features that aren’t available in the 5.0 release series. There have been huge improvements to stored procedures and functions, for example.
We’ve been running MariaDB 5.3 as our core internal database for awhile now, and it’s done very well for us. And, more good news, moving to MariaDB 5.3 from MySQL 5.0 doesn’t require the clunky system table upgrades that 4.x to 5.0 did. You won’t have to do anything to take advantage of the change, and everything will continue to work just like before, except faster and with more optional features available for those who want them. However, we will also be taking this opportunity to rebuild all of our MySQL nodes with the freshest OS and software updates and additional resources allocated. This will require brief downtime (typically about 5 minutes) for each MySQL process as we migrate it from an old node to a new one.
These upgrades will be on a node-by-node basis, and we will preannounce the moves on Twitter. You can see what node your MySQL process is using at any time in our member interface. For example, the first new node (which is currently out of service) is m2, and the first move will be from old node m1 to new node m2, and we hope to announce that in a couple of days. Then, once m1 is empty, we will take it offline, rebuild it, and announce a migration from another node to that one. Then repeat the process on down the line until everyone is on the new hotness.
There are still 54 MySQL processes running on an old MySQL 4.x node (m6). Extended support for MySQL 4.x ended in 2008. It’s 2012, so we’re going to go ahead and push those processes through this upgrade. The processess should continue to work, but will require those members to upgrade their system tables as described in our FAQ before using their process with phpMyAdmin or changing any usernames or passwords in the future. We strongly urge those few people still using MySQL 4.x to avail themselves of our free “Upgrade MySQL 4.1 Process” assistance request to upgrade to MySQL 5.0 at a time of their choosing rather than waiting for an involuntary upgrade.
Update: While converting everyone to MariaDB, we found a way to reduce the per-process overhead, bringing the median process size down to 3.25 MiB, and the 90th percentile down to about ten times that (32.70 MiB). Despite this, the base space allocation will remain at 40MiB — it’ll just give everybody that much more headroom.
If you want to participate in the SOPA/PIPA blackout, we’ve got your back. We’ve added a UI option on the site info panel for each site that, if enabled, will make your site look like this. If you select this, it’ll last until about Thursday at 7am UTC. Then, we’ll switch it off and convert it for people who want to be able to switch it on and off over the next week.
We set all the appropriate status and caching headers so that this shouldn’t have any long-term consequences or impact on search engine rankings. (But of course we can’t guarantee that since search engines are notoriously tight-lipped about how such things are determined.) We will return status 503 (Server temporarily unavailable) which should convince the automated world that we’re simply down. Not so good for us, but worth it for the cause. We’re also telling the world not to cache the results, to keep trying hourly, and that the content expires Thursday at 7am UTC.
As previously pre-announced via our status feed, the cost of domain registrations will be going up on January 15th, 2012 from $8.99/year to $9.49/year.
There’s really not much to add other than that. This is in response to a change by our registrar, who are responding to Verisign once again exercising the “because we said so” clause in their license to print money, which allows them to raise prices by a percentage every year for no reason at all.
We do have long-term plans in this area, including trying to break loose pricing on gTLDs other than .com to help them compete, but nothing coming to fruition in a timeframe that would affect any decision making anyone has to do about this.