fluffy wrote:Yeah, Dreamhost's VPSes are overpriced garbage
Yeah. I didn't really want to be a negative Nancy, but yeah.
fluffy wrote:Do you think Drupal is really too resource-intense for a shared hosting setup though?
Technically, no. However, I'm thinking more about the performance of the site. Depending on the number of concurrent users on the site, you can suffer some pretty bad performance issues beyond (let's say on average) 1-2 dozen users hitting it at the same time. You can accommodate up to that number via the configuration of Drupal's internal caching mechanisms and with some modules and plug-ins that assist in the way that MySQL caches queries, but realistically, the greatest gains come from being able to add services that speed up the performance of MySQL and PHP more directly, by tuning your mysql.conf, your php.ini, and most importantly, adding things directly to the stack like an APC, FastCGI or Opcache daemon to speed up the performance of PHP, by creating a RAM disk for storing the most commonly-accessed static resources in the past day or week (e.g. songs from the current fight), and by setting up a Varnish or Nginx reverse proxy overlaying everything else for the least-dynamic pages, nodes or blocks of pages (e.g. artist bios, FAQs or forum pages served to unauthenticated users).
The bottom line: I'm not just looking at what WILL run... I'm looking at how your site will perform and scale on the platform. In practice, you'd ideally have something that is always stable, capable of handling traffic spikes (if Frontalot decides to compete again and blog about it, for instance, or getting attention again from Penny Arcade or Slashdot or Reddit or whatever) and is user-friendly (which generally means getting the page in front of the user and interactable in less than half a second from the initial request, and keeping RESTful requests sub-200ms).
fluffy wrote:Or does it require a persistent process or some weird mod_php configuration?
Essentially, yes; both.
fluffy wrote:Keep in mind that as large as the Song Fight site is, we actually don't handle a whole lot of traffic, nor are we a target for DDoSing or targeted hacks or the like.
Duly noted, but also bear in mind that we're accounting for search engine crawlers, which will visit your site far more frequently if the content is well-formatted for search consumption (for instance, your completed fights can be structured with Schema.org data that the crawlers can aggregate if you validate the parameters in Google's Structured Data Testing Tool, which in turn will cause you to rank more highly in SERPs and get more click-throughs as rich content is often highlighted via Google's Knowledge Graph engine).
Long and short of it is, ideally we plan for scalability, not necessarily accounting for past results as the primary metric for how you'll grow in the future.
fluffy wrote:JB and I already know about many other VPS options
Yeah. There are some great ones. I have a couple servers that cost about $40 a month with redundant SSDs, ludicrous upstream bandwidth quantity and speed, and pretty much act like standalone boxes despite living on virtualized hardware.
fluffy wrote:... we've also been toying with the idea of just AWS/Heroku-ifying everything
I'd strongly advise against using AWS if you decide to do that. It's crazy expensive compared to literally any other option, and I'm speaking from experience as someone who's had several AWS EC2 instances running for the past 5 years, both personally and for clients. Honestly, if you're going to keep your data on Heroku, Firebase, Hoodie, etc. you can just as readily build a bespoke client-side single page app that GitHub will happily host for you, for free, with the best uptime and content delivery speed in the business (for instance, I currently host cr8s.net there, although I'm not doing anything with the domain at the moment). Yes, your client-side software would be prospectively open-source at that point, but I don't see that as a negative thing at all. Since you mentioned you have a private GitHub instance, which I'd assume you're paying for, you wouldn't even have to open-source the platform if you didn't want to.
fluffy wrote:Nice thing about Dreamhost shared hosting is they already take care of hardening and do a pretty good job of it.
Yeah, I definitely agree with that; however, they are also a common target for attacks on the broader scale, and I have definitely seen clients on DH disrupted because an entire ARIN block was taken offline temporarily via a DDoS attack on someone else entirely, and the client had the misfortune of being in the same block.
fluffy wrote:I also have a nightly rsync-over-ssh process to back up my own crap and vital Song Fight stuff to my home NAS and to Crashplan (including the private git repo for all of the site scripts). And of course I have a complete mirror of the Song Fight! archive in my iTunes library, although with all the id3 tags normalized.
Brilliant; my preference is rsync over SSH as well. You obviously know your shit... so, I'd suggest that whatever software and server solution you go with, you continue backing up via the same methodology.