Significant pricing updates are coming soon

I’ve started and stopped writing a bunch of posts over the past few weeks. Recent events have really crystallized some issues that we’ve been looking at for over a year. Those posts are largely ideological in nature, and they tend to ramble on at very great length.

This isn’t intended to be such a post.

This is a post to acknowledge that our service has a couple of serious issues that require more urgent attention.

1. The cost and threat of DDOS attacks is escalating so quickly that unless we act, they will drive us out of business.
2. It’s time for us to move toward ICANN accreditation.

Addressing these concerns will require some major shifts in our pricing model. To be completely honest and upfront, these changes will primarily affect those sites and members that are currently paying the least. After the changes, the prices at the low end will still be low, but not as low, and in some cases, lower-cost sites may have a different set of options than they have in the past.
Continue reading Significant pricing updates are coming soon…

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%.
Continue reading More power, more control, more insight, less cost….

Price cuts, more security and recovery options

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…

MySQL upgrades and pricing changes for extremely large processes

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.

Service & pricing changes finalized

Our recent announcement that we were preparing to make pricing changes provoked quite a bit of discussion that resulted in significant improvements to our plans. (Please see both links if you want more information about the rationale and justification for these changes; both have been discussed in exhaustive detail.)

Those plans have now been finalized, and we will begin phasing them in this month.
Continue reading Service & pricing changes finalized…

Pricing changes incoming

NearlyFreeSpeech.NET was founded with no intention of ever turning a profit. There are no investors to pay off, no debt to service, and no short-term-focused shareholders measuring ROI with three-month horizons. NearlyFreeSpeech.NET exists because I want to provide as many people as possible with affordable hosting free of “big company” restrictions that come from pleasing investors, debtors, and shareholders. Therefore, all the fees we charge are designed to cover the costs of the resources it takes to provide the service.

One of the things we are running into with our pricing model is that the resource-based pricing we currently use doesn’t take everything into account, and doesn’t always do so accurately. That’s something we need to address.
Continue reading Pricing changes incoming…

Breaking through the bandwidth barrier

One of the things that we have always wanted to do is deliver bigger bandwidth discounts to our members. Our 1GB/$1 pricing is ideal for sites that don’t use much bandwidth. But we’re painfully aware that as the gigabytes pile up, the costs pile up proportionally.

What if they didn’t?
Continue reading Breaking through the bandwidth barrier…

Domain prices increasing October 12, renew now!

As you may be aware, most registries have announced they are increasing prices by the maximum their contracts with ICANN will allow. We’ve finally received information about when and how this change will affect us.

On October 12th, our pricing for all the top-level domains we support will increase from $7.50/year to $7.99/year for all domain registrations, renewals, and transfers. All other pricing, including RespectMyPrivacy.COM, will remain the same.
Continue reading Domain prices increasing October 12, renew now!…

Revising member support to better support our members.

Here are some eye-opening support statistics:

• About 25% of our members have ever interacted with our support system.
• About 14% of our members have opened more than one support issue.
• Over 50% of our support issues come from under 5% of our members.
• Providing support is our single largest recurring monthly cost line item. That means it costs us more than we pay for bandwidth.
• The cost of providing support is growing at a faster rate than any other cost.

Continue reading Revising member support to better support our members….

MySQL pricing changes effective 1/1/2007

Since we started, we have never imposed a charge for MySQL processes, choosing instead to fund MySQL out of the general hardware fund provided by the storage charge.

However, as time goes on, MySQL is becoming more of an issue. Not only is each successive release more demanding in terms of CPU and memory, but as time goes by, the things our members are doing with MySQL become more intensive as well.
Continue reading MySQL pricing changes effective 1/1/2007…