Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: dreamhost

  • Dogfooding DreamPress

    Dogfooding DreamPress

    While I work for DreamHost, and I’ve used DreamPress since day one, I haven’t have the opportunity to put a serious, stress site up on it. The reason for that is simple. The two sites I have that I might do that for are ineligible for pretty much all managed WordPress hosts … because they’re not 100% WordPress.

    But. There is one domain that is, and I’ve moved it over. And this gives me an opportunity to determine what needs to be done to this site to make it fly on a different host.

    All Hosts Require Site Tuning

    This is possibly an unpopular opinion, but no matter which host you pick, there will never be a ‘drop it in and forget it’ option for any web host. The reason is that no two sites are the same. No two sites use the same code, have the same data, and have the same traffic patterns. And all those things come together to determine how well your site will run.

    No matter who your web host is, you will have to adjust. It may be something as simple as editing an .htaccess file or removing a plugin you no longer need. Maybe it’s as complex as PHP settings or having someone write you custom code.

    I don’t mean to say that no two hosts are equal, or that one is better than another. What I mean is that no two situations are identical. Of course a site will work, out of the box, better on one site than another. But when we have the capacity to understand what it is that makes our site work, what it does and how it does it, we can make any site work on nearly any host.

    For DreamPress, I Made Four Changes

    After I moved the site over to a test setup, I quickly debugged the ‘big’ issues. I had a white screen of death. Thankfully I knew right away what it was, because I was clearly aware of what went into my site and how it worked.

    First, a lot of sanity checks I’d put in to my .htaccess didn’t work. Primarily it was a case of how I’d handled redirects, since I was using an Apache4 format that didn’t work universally.

    Second, I wanted to use a phar file, so I had to add custom lines to my PHP settings to let it know how to run properly.

    Third, I replaced the old caching system with the new one. DreamPress has Memcached and Varnish, so I removed some of the object caching I didn’t need anymore.

    Fourth, I wrote some customized code to teach my site how to talk to Varnish, since I do weird things.

    That’s it. Four things. And I was able to debug this in about an hour because I took stock of the moving parts of my website. Not everyone can do this, I understand that, but when you build out a website, even if you can’t code, it’s incumbent on you to document what you did.

    When you add a plugin or a theme, you need to make a note somewhere of what it is and why you did it. I recommend someplace not on WordPress, since if your site is down, it won’t do you any good at all.

    The Immediate Impact

    With those four changes, the result was immediately obvious.

    A change in page timings - basically everything went balls faster.

    In the chart above, there are two major drops in speed (in this case, a drop is good). At the end of July, I reoptimized how images were processed by using Photon via Jetpack, I applied caching for FacetWP, and I removed all Google Ads. In doing so, I halved my time to load. This is a great thing.

    But then, just by moving to DreamPress and doing no changes to code, I halved it again.

    The average site load is now .8 seconds. It ‘spikes’ to 1.2 seconds if you hit a non-cached page. The time to first byte, which is shown on the graph as the yellow/orange line, went from 1.6 second to .1 second.

    Was Everything Perfect?

    No. But as it turned out, everything that wasn’t perfect had nothing to do with my new hosting setup. I reproduced the site locally and found I had some seriously slow database queries on a couple pages, which resulted in poor load times. Once I fixed that, a few of my archive pages began to fly.

    Also as I mentioned in the four things I changed, I did have to write new code. The bonus for the new code is that I was also able to back port some of that into the Varnish plugin itself, which means fewer people will have to write that code. You’re welcome. But that really was more for convenience as the site ran fine, it was just a bit overly aggressive in caching.

    Is DreamPress Right For Everyone?

    No host is right for everyone. Period. End of conversation.

    Is it right for you? Maybe. It certainly can be, and not just for generic ‘blog’ type sites. But you have to know what your site does, who uses it, and what they do to really know the right questions to be asking.

    The question isn’t “Is this good for me?” but “What does this do to a site that does what I do?”

  • Listing Everything on DreamObjects

    Listing Everything on DreamObjects

    I was asked about listing everything in a DreamObjects bucket, which is practically the same thing as listing everything in an Amazon S3 bucket, just on a different server.

    This isn’t as easy as we’d like, because while there is a nice Amazon S3 PHP class we can use (and I forked it and flipped it to be a DreamObjects PHP Class), telling people they have to download the S3.php file and then make this separate PHP file is a little annoying.

    //include the S3 class
    if (!class_exists('S3'))require_once('S3.php');
    
    //AWS access info
    if (!defined('awsAccessKey')) define('awsAccessKey', 'MYACCESSKEY');
    if (!defined('awsSecretKey')) define('awsSecretKey', 'MYSECRETKEY');
    
    //Bucket Info
    $bucketName = 'MYBUCKETNAME';
    
    /* STOP EDITING HERE */
    
    //instantiate the class
    $s3 = new S3(awsAccessKey, awsSecretKey);
    
    
    // Get the contents of our bucket
    $bucket_contents = $s3->getBucket($bucketName);
    
    foreach ($bucket_contents as $file){
    
        $fname = $file['name'];
        $furl = 'http://'.$bucketName.'.objects.dreamhost.com/'.$fname;
    
        //output a link to the file
        echo '<a href=\'$furl\'>$fname</a><br />';
    }
    

    I know, it’s not too terribly complicated, but it is annoying to make two files for that, and my DreamObjects listing page is very barebones. You could style it with CSS, make it show the image, make it show in a grid, or even show the file size and have it pop up in a new window.

    It does highlight one of my issues with CEPH (AWS whatever) storage, and that it’s still not quite friendly enough. It dumps us back to the old days where we FTP’d our images up to a server and then manually crafted our links. Certainly there are plugins for WordPress that can help us with that, but in general it requires knowing code (or where to get the code) in order to display content.

  • Separate Users Are Good

    When you create a new domain on DreamHost, you can chose to make a ‘new’ user to ‘own’ the site, or use an existing one. There are pros and cons to both, but for anyone who comes from the cPanel world (where separate accounts are de rigueur), it’s pretty normal to expect your separate site to have a separate login name and password.

    Explaining how all this works on DreamHost is a little different, because we have users and then we have users and … well let me explain.

    There’s more than one kind of user

    The first type of ‘user’ you have at DreamHost is your panel user. This user is the one you make when you sign up, and it’s usually your email. Don’t share this password with anyone, okay?

    Next we have your ‘users’ which you can find in your panel. Those users are the ones who have access to things like ‘shell’ and ‘sftp’ and so on.

    Then there are also those ‘other’ users you think of, like the login accounts on your blog, or your email, or maybe even the billing account for DreamHost.

    When I talk about separate users, I’m only talking about the ones who have access to shell and stuff.

    Users own sites

    Those user accounts own sites. That means I have a specific user who ‘owns’ the folder on the server where all my web code lives. And you can see it’s that user because there it is, in the path: /home/USERID/domain.com/

    Only one user can own, and access, a domain. However a user can own multiple domains.

    So here’s what this looks likes. One user owning multiple domains:

    one user multiple domains

    And only one user can access the domain, user two cannot:

    User 2 has no access

    This is cool because if there’s a domain under User 2, and it gets hacked, there’s no way for User 1 to get hacked, even if both users are you!(Unless there’s a server wide security flaw, which yes, can happen, but we spend a lot of time trying to prevent that.)

    Logical User/Domain Groups

    If you own 50 domains (and I’ve seen users with 200!), having them all owned by one user sure seems easier, but it means if that user gets hacked, they’re all vulnerable, and you’ll probably end up having to de-hack 50 domains at the same time. Instead, it’s wiser to group your domains ‘logically.’ For example, my elftest.net domains have subdomains, all of which are owned by the same user. However my other top-level domains are each owned by their own user. But that doesn’t work for everyone.

    Recently I was helping a customer with a hacked site, and he complained that the sites he hosted for his clients were being hacked, and his clients were pissed off. I took a look and saw that all his client sites were under one user ID. I asked him if the clients had more than one domain, or if they all had their own, and he replied that each client had 4 or 5 of the domains. After cleaning up the hack, together we made new user accounts, one for each client, and moved the domains to those accounts. If possible, I always clean before moving, but in one case the customer had 75+ hacked sites, so we moved and then cleaned each one, prioritizing the accounts on the way. It took a very long time.

    109649_D_0989 The extra benefit to this is the clients can now have FTP access to their domains and do wild and crazy stuff! But we don’t want them to have FTP.

    Moving The Domain

    Obviously first you need to setup users. When I set up a new user, the first thing I do is make it secure. That means I turn off FTP, forcing SFTP only, and if needed, give them Shell access. Personally? I love shell access, so I always leave it available. If you’re using DreamPress, we have Shell turned off by default, but you can activate it.

    Secure User Settings

    There is a downside, which is that the WebFTP app won’t work. Personally? I find 99.999% of WebFTP apps to be total drek. They’re messy, kludgy, and there are some great free apps like Cyberduck which even let you connect with DreamObjects!

    Now that you have the user, we want to move the domain. This is so easy, anyone can do it. Go into Panel, click on domains, click on edit for the domain. Go to “Users, Files, and Paths” and change the user in “Run this domain under the user:”

    Changing Users

    Really, it is that simple.

  • DreamCon In Review

    DreamCon In Review

    atimThe weekend after WCSF I talked at DreamCon, which was our own little Webhost convention/camp for technology and other things. As Matt said, we’re kind of the wacky Webhost, and I love it that way here at DreamHost.

    Some of my coworkers talked about the technical stuff, like WP-cli and how DreamPress works, but I talked about some slightly more esoteric and conceptual things, no coding involved topics, because I tried to think about the questions people who host with us asked me the most.

    Choosing WordPress Plugins

    This was the more geeky of the two, but was an overview on how I search for plugins, value the devs and their work, and determine which ones I use. I mentioned needs and wants a couple times, which makes me think I’ll end up giving people a talk on that one of these days…

    The questions I got after this session were interesting. I preemptively answered the long standing question I had never been able to answer before, which is “What is your favorite plugin?” I finally have an answer, and it’s MP6. My eyes suck, and for me, MP6 finally made the back end of WordPress totally readable for me, without having to increase my browser’s font size. The font was better, and larger, and clearer. Normally I hate black backgrounds, but for some reason MP6 doesn’t give me headaches.

    The best question I got was how to search effectively. My answer was to be more exact with search terms. Too often we go for broad terms and narrow down, but I like to go the other way. “wordpress plugin calendar event list” – I pick every major term I need in that plugin, and more precise results follow.

    Get Out Of The Monkey House

    Besides the fact that all the devs in the room cheered when I stated “code is art” I think this one really opened people’s eyes. Remembering that the design of your site doesn’t stop at the pretty stuff, that your content and the flow of how the site works is also a major impact, is huge.

    By the way, code is totally art. You’re making something out of nothing, inventing and building a concept that never existed before. It’s just like writing music. Be proud of it. The most standout question from this talk was what do I do when a customer demands they stay in that monkey house? I put my foot down. When I get into contract work, I have always stated up front “You’re hiring me to be your expert, which means you may suggest things for your website that I, out of my experience and expertise, know to be bad ideas. When that happens, I will tell you that we should not do these things, and why. This is my power of veto. I will only use it when I have proof, via research, that what you are proposing is not in your best interests. If that’s not okay, then we don’t sign the contract. If it is, then you will accept my actions on web design, just as I will accept yours about your product. You know more than I do about that, I know more than you about this.”

    tumblr_ma1mh5Cpbs1rdkmnho1_500

    Thus far, no ones walked away, and I’ve never made a website with a blink tag (except for the gag website, where the contract was to make it look like Ling’s cars…).

  • Upcoming Speaking Gigs for DreamHost and WordPress

    header_logo

    • WordCamp San Francisco – July 26-29 (“Don’t Use WordPress Multisite”)
    • DreamCon – Aug 2-3 (“Choosing WordPress Plugins” and “Get Out Of The Monkey House”)
    • WordCamp Portland – Aug 10 (“Rolling Your WordPress Support Character (without any code)”)

    You get me twice at DreamCon. Twice the elf for one low payment!

    I believe all these will be recorded and made public.

  • DreamPress: We Went There

    DreamPress: We Went There

    Not the most flattering picture of me...
    Not the most flattering picture of me…
    One of the projects I’ve been involved with since I started here at DreamHost has been a secret. Actually two of them were, but we released one already. Anyway. The one we pushed today is DreamPress!

    What is DreamPress? Here’s marketing:

    What is DreamPress? That’s a good question! Think of WordPress. You got it? Cool. Now, think of that WordPress install, but on steroids! Picture it running on a specialized, optimized, virtual private server. Yeah, this is far from your average WordPress hosting package, isn’t it? DreamPress comes pre-configured by our in-house WordPress experts for maximum security and performance under traffic load. This is our call-out to all entrepreneurs, website designers, developers, and bloggers to give it a test-drive today!

    And here’s me:

    If you did your job really well, one day you woke up to a downed website becuase you swamped it with traffic. I’ve been there, you’ve been there. There’s a point where your host reaches out to you and says “Honey, sweetie pie, you’re too big for shared hosting.” And as horrible as this is, it’s a good thing! You’re popular! Of course you’ll try caching and changing themes and plugins, but there’s just that moment when, damn it, you’ve got to step up and go up to a VPS.

    And you know what? A VPS is scary. I started this blog when I got my VPS because I wanted to learn how to manage it. But you see, I’m weird. I know it, you know it, that’s okay. I’m strange and I like me, just the way I are, and this works for me. It doesn’t work for everyone, so when you find yourself faced with something new and different, maybe you don’t want to learn it. Maybe it’s not your thing. So looking at that VPS is a great big bag of nope.

    Screen Shot 2013-06-04 at 3.37.07 PMThis is where managed hosting steps in. Hosts take on the job of managing your server. We handle upgrades (which yes, we do anyway), but we also optimize and customize the server. All the times you hear me talk about ‘Edit your httpd.conf’ or ‘installing PageSpeed…’ is something we’ve already done for you. Need more memory? We’ll take care of it without bothering you. It’s a VPS without the responsibility. PHP memory, server power, even caching is taken care of. Oh yes, you no longer need any caching plugins, because we’ve got Varnish in front for you.

    Of course, this isn’t perfect for everyone. Hard-core code jockeys may want that VPS (or dedicated) to play with the nuts and bolts, install extra add-ones, and just go to town. But if that isn’t for you, come check out DreamPress. I promise we’ll have a magic button to migrate things soon!

    Nifty articles on DreamPress:

    I know there are a lot of hosts out there. I work for one, I use others, and I think the more of us who get into this supporting the app that needs supporting, the better experience for everyone. Bring it on, baby!