If you’re reading this, then DNS has propagated (non-techie: it’s what tells the Internet where websites are and how to find them, and can take up to 48 hours) and you’re seeing Gnome Stew on our new server.
We’ve been keeping folks updated on our progress through Twitter (@gnomestew) and Facebook, since the site itself wasn’t viewable. I didn’t announce the move here beforehand because the opportunity to do it came together in a rush, and I needed to take it; I should have posted in advance, though, and I’m sorry that I didn’t.
The site was down from roughly Friday evening until Sunday very early in the morning, which is how long it took me to make copies of the old site, set up some stuff on the new server, transfer everything there, screw up several times, accidentally ban myself from the new server, and make sure it all worked properly.
I apologize for the downtime, and thank you for bearing with us. I think the improved site performance will be worth it.
We’ve been having issues with site slowness, loading times, and internal errors recently, and after trying some behind-the-scenes fixes I asked our hosting provider if we’re reaching their resource limits for shared hosting. They confirmed that we regularly hit those caps, which means Gnome Stew has officially become too big for shared hosting.
That’s pretty cool, because it means the site is growing and people like it, but it also feels weird, because the Stew started out as a fun project just a couple of years ago — hearing that from our provider was definitely a “Whoa” moment.
Why did we upgrade?
We upgraded to improve the performance of the site in order to make sure that our readers can continue to enjoy the Stew. The Stew doesn’t do anyone much good if you can’t load pages quickly, get site errors, or otherwise have a poor experience when you visit.
Moving to a new server means that those problems should be a thing of the past. The site should load faster and perform better now than it did before.
What did we upgrade?
Up until now, I was hosting the Stew on a shared hosting account I use for a handful of personal websites. Shared hosting is inexpensive ($10 a month), and works great until traffic and resource needs reach a certain point.
The Stew was on a server with a large number of other hosting accounts, all sharing resources (RAM, disk space, etc.), and in order to make sure no single site in the mix overwhelms the others, each account is limited to a certain undisclosed percentage of those resources — and there’s no guarantee that you’ll get X amount of resources. We reached that limit.
We’ve now upgraded to a virtual private server (VPS), which means Gnome Stew shares a server with a small number of other accounts, each of which is guaranteed dedicated resources. The main thing we needed was RAM, and we now have that in spades: 768 MB all to ourselves, which should be enough for the foreseeable future. We also get 2,000 GB of monthly bandwidth, which is dramatically more than we need; ditto with 40 GB of disk space.
Our new host, KnownHost, has an excellent reputation, and their support throughout the server move has been awesome.
What does it cost?
Our old hosting was free to the Stew; I was already using it for other things, so I just included the Stew on my $10/month account. The new server is $34 a month, or a bit over $400 a year — a dramatic increase from free.
We can usually cover that amount through ad revenue, and we have some capital on hand to absorb a few slow advertising months. We’re not going to start charging for articles, or anything like that — it’s important to us that the Stew be free for everyone.
We will be introducing a few low-impact ways to support Gnome Stew, though, starting with an Amazon affiliate account and a DriveThruRPG affiliate account. I’ll post separately about that when we get those up and running.
Holler if you find a bug
If anything doesn’t work the way it’s supposed to, please drop me a line at martin (at) gnomestew (dot) com and I’ll take care of it.
Thank you again for bearing with the downtime, and I hope you agree that the move was worth it!
Great to hear, Martin! Thanks for being up front about everything. Glad all is well, and grats on even more indicators of continuing success!
Great job Martin! It is wonderful to be part of a site that just had a “Whoa!” moment.
http://www.youtube.com/watch?v=wQ5iFQv1KaE
🙂
Hehe. I had expected Patrick’s video link to lead to this:
http://www.youtube.com/watch?v=5fC8EAQ8xhM
I should also mention that, as our single biggest resource hog, I’ve removed the plugin that displayed related articles under each article. I’ll miss it, but for the time being we’re better off without it.
@Rafe – I’m big on transparency. If you have any questions, just ask!
@Martin Ralya – I’ll kind of miss that ‘related articles’ box, but I can understand why you’ve removed it. Though, would it be too much to maybe just turn that into a single link at the bottom of the post that makes a page that lists a search based on articles similar to the one you just read?
Keep up the great work guys, and congrats on the new move!
@E-l337 – I’m not aware of a way to do that, although it’s an excellent idea. If it requires coding, it’s probably beyond me; I’ve never seen a plugin that works that way.
The reason that plugin was so resource-hungry was that every single time an article was loaded by anyone, it polled the entire database of 800+ articles, checked for matches, ranked them, and spat them out — all before some of the page could load.
@Martin Ralya – This has actually been bothering me ever since I read that you took that feature out, but I didn’t want to get into a whole thing about it on the Stew. But, well…I guess I will now. 🙂
I figured that was the reason it was so resource-heavy, and at first I was thinking, “Well, that’s not a good way to make that work,” but then I realized it was probably so that articles in the past could, when viewed, be changed to relate to articles that come later.
I figure to lighten the load, the lists can be made static. One way is to make them so that the lists are generated when the article is posted, which I guess would mean articles would only ever reference articles written previously…so maybe that’s not so hot.
The other thing is…you could have the related article lists generated when new articles are posted…maybe have it done asynchronously, or (if that’s not possible) done at new article post time…so basically when a new article is posted, all the other article’s lists are updated if need be. Not sure that would be practical. I like E-l337’s idea, too…generating the list when it’s requested, rather than for every page load.
If you had your choice, Martin, how would you wish a resource-lighter version would work? Also we can take this discussion offline if you like. 🙂
@Rob Abrazado – You know, Rob, I think that the plugin may actually have a setting for “generate once, never touch it again.” Which would be an imperfect middle ground, but not a bad idea at all.
If I had my druthers, it would update an article the first time it was polled in a 24-hour period, and then not again for 24 hours. So if 800 people read today’s piece, the first reader’s load populates the list and the other 799 see that list. Ditto for every article on the site.
Happy to discuss here or via email, whatever works best for you!
@Martin Ralya – Ah, yes! I like that. Probably the least amount of alteration from the original plug-in’s functionality, too. Dig it.
What are you doing…don’t you have a deadline and a headache? 😉
@Rob Abrazado – Microbreaks!