DreamPress 2: The Evolution of Managed WordPress Hosting at DreamHost

DreamPress 2: The Evolution of Managed WordPress Hosting at DreamHost thumbnail

By Micah Sachs, VP of Systems Engineering at DreamHost

Redesigned from the ground up with a new OS, updated PHP 5.5 with OPcache, optional Hip Hop Virtual Machine (HHVM), and all sitting on blazing fast Solid State Drives, we are incredibly proud to announce the release of DreamPress 2, our fastest WordPress hosting platform yet!

When we set out to create the first DreamPress, we were already a little late to the game. Several companies had successful products centered around removing all the management headaches related to making WordPress snappy and low maintenance on top of traditional hosting. We’d kicked the idea around for a while and decided to do a minimally viable product to see if our hypotheses were correct; That A) We have unique expertise that could help WordPress power users get their site(s) running quickly, performantly, and with minimal fuss, and B) There had yet to be that killer service that had both the price point and the features set to satisfy the widest swath of customers.

Fast forward one year and thousands of customers later, we believe we had not only answered those questions, but learned enough about ourselves as a company, what our customers want, and what the WordPress community deserves to make substantial improvements to the original DreamPress.

Do More with DreamPress

DreamPress' automatic updates and strong security defenses take server management off your hands so you can focus on content creation.

When we saw this review we decided it was time. SSDs had already been popular in our VPS product so it seemed like a no-brainer to bring them to our most performance-tuned offering. As we started looking deeper into performance for specific types of traffic we decided to focus on improving how DreamPress 2 could serve more concurrent users, overall throughput, and dynamic content. We started benchmarking our new configurations; Here is just a snippet of what we discovered:

Details PHP 5.5 HHVM*
Caching OPcache n/a
Transactions 712 hits 2777 hits
Availability 100.00 % 100.00 %
Elapsed time 59.12 secs 59.33 secs
Data transferred 3.70 MB 13.64 MB
Average response time 1.23 secs 0.32 secs
Transaction rate 12.04 trans/sec 46.81 trans/sec
Throughput 0.06 MB/sec 0.23 MB/sec
Concurrency 14.75 14.95
Successful transactions 702 2742
Failed transactions 0 0

*HHVM is Facebook’s uberfast PHP replacement.

Each test was performed several times and the above results are averages. Set at 15 concurrent virtual “visitors” configured to hit the stock WordPress install as many times as possible in 60 seconds, you can see that the PHP5.5 with OPcache runs handled approximately 12 transactions per second and HHVM just crushed it with almost 47 transactions per second. Wow! And if you add the fact that very few managed WordPress hosts are offering it (WP Engine and Pantheon at the time of this post) we just had to have it.

After some more fiddling with Memcached and Varnish caching options, we used Loader.io to dive a little deeper into the performance of dynamic traffic, which isn’t as easily enhanced by caching due to the fluidity of the content. Here’s what we found:

PHP5.5 w/OPcache Non-dynamic
Concurrent users 100 500 1000
Average Response Time: 26ms 23ms 23ms
Min Response Time: 8ms 7ms 7ms
Max Response Time: 125ms 927ms 1069ms
Total Hits per Minute: 288 1234 2077
Error Percentage* 0.0% 0.0% 0.0%


PHP5.5 w/OPcache Dynamic
Concurrent users 100 500 1000
Average Response Time: 286ms 1217ms 4776ms
Min Response Time: 235ms 251ms 274ms
Max Response Time: 335ms 5352ms 304000ms
Total Hits per Minute: 282 1455 2330
Error Percentage* 0.0% 0.0% 11.8%

* Error percentage does not include 404s which were intentionally built into the tests

You can see that for non-dynamic sites the performance stays extremely even with 1000 users continuously hitting the stock WordPress for 60 seconds. For dynamic content – for instance, content which has any database interaction – the results stayed about the same for 100 concurrent users and then the average response times started climbing. We used the results of these and other tests to build out the 2.1MM pageviews-per-month metric for the new offering.

The best part of this major overhaul is that we’re extending all the hardware and software upgrades to all of our existing DreamPress customers. We’ve already started migrating them to DreamPress 2. Due to the premium nature of the SSD drives, we’re instituting a 30GB limit, but our research shows that 99% of our existing users don’t even come close to that. For those that do, we’re working with them directly to find a solution for their storage needs.

Here are all the great features that are available today with DreamPress 2.

  • We tuned Memcached, the application caching layer we use for WordPress
  • We performed OS upgrades across all running installations from Debian 6.0 “Squeeze” to Ubuntu 12.04 LTS “Precise”
  • We upgraded both WordPress itself from 4.1 to 4.2.2 and PHP from 5.3 to 5.5
  • The PHP upgrade allowed us to scrap XCache in favor of the more efficient OPcache
  • We forklifted in a highly efficient PHP replacement from the labs of Facebook, HHVM

Some of the features that are on the proposed roadmap for future releases, besides further performance improvements, are faster deploy times and multiple DreamPress installs on a plan. This isn’t the last you’ll hear about DreamPress 2 this year… Stay tuned!

About the Author:


    1. Hi Disgruntled,

      Yes, the current MySQL version running behind all of the DreamPress 2 (and OG DreamPress, as well as all VPS) guests is an abysmal 5.2, and yes, that is far from optimal. We have Systems Engineers and our Senior DBA working on rolling out MySQL 5.6 as quickly as possible.

      We tend to opt to change things for more than just small bits of our infrastructure to get the most out of our testing so it while it might be rolled out to VPS or DreamPress 2 first, it’ll be applicable to our userbase as a whole, and testing for this big of a jump in versions for that large of a subset of customers is no small feat. This isn’t an excuse, we’re definitely behind the curve on this, but it isn’t a small thing to test a change that can seriously impact hundreds of thousands if not millions of customer sites.

      I’m sorry you felt it was in some way disingenuous not to include. Please feel free to let us know if there’s anything else we can improve on!

      1. People feel cheated because the website doesnt mention that you have such an old version of MySQL. Atleast write it down on your sales page. Newer wordpress websites are difficult to transfer

  1. The best part of the post (for me)

    The best part of this major overhaul is that we’re extending all the hardware and software upgrades to all of our existing DreamPress customers.

    Keep going guys!

  2. I recommended this product to a client, but have found that whatever protocols you have in place make it impossible for me, the web developer, to use. The extra layers around the database are impenetrable.

    I develop on a virtual server. the fastest way for me to move a wordpress install from that location to a client server is to copy the database and import it via phpMyAdmin, and then change the settings in the database to reflect the new site location. And then upload the wp-uploads folder with theme, site files, and plugins to a new wordpress installation.

    Yet you require this other process in addition to the phpMyAdmin import, documented in your help documents here: http://wiki.dreamhost.com/DreamPress#Migrating_NON-One-Click_Installs, that involves SSHing into the site to “complete the process” of moving the database over. Not only are the instructions incorrect (does not correctly tell you WHERE you need to be doing this), but it doesn’t work and produces an error, because the database already exists, and so it produces an SSH error stating that it can’t import items because the database already exists.

    So if you then wipe the database via phpMyAdmin and retry this import in the correct location, you get a success message, but then install fails to connect to the new database, anyway.

    I’ve had several back and forths with your customer support about this. During the last one, they deleted my database entirely, told me everything was fine, and suggested that my credentials weren’t correct. Thanks, I know what my credentials are.

    I’m the snake eating its own tail, here. Apparently I’ve got to rebuild the site from scratch on your servers if I want it to live there?

    I understand that “managed” means an extra layer of security for the non-technically inclined client, but that doesn’t mean that the technically proficient should be barred from using standard protocols to simply make changes to a site.

    I sincerely hope you can find a way to allow admins to make standard edits to the database that actually work, and that you can update your support documents to reflect an accurate way in which people can use your product so that it functions.

    1. Hi mandm!

      It definitely sounds like you ran afoul of one of the caching layers and we’ve looked into how we can improve the documentation and TS training on that subject better. I wasn’t able to find a support ticket from you about this but if you’d like to discuss further or need further assistance please let me know. I agree with you, getting your site onto DreamPress should have been easier, and we should have been able to help.

      Thanks for the feedback!

  3. That’s a lovely article ! I found it because of the review you first mentionned that was heading back to this blog post. I am pleased to find that Dreampress2 will be much more performant than the first one reviewed.

    Thanks for the stats.

Comments are closed.