Moving Again... And a Couple Updates [UPDATED]

[UPDATE: Everything should be operational again. Please let me know if you have any trouble logging in or posting information!]

Well, after a few weeks on Slicehost, I've decided to switch to a different VPS with a company I've grown to like very much—Hot Drupal—and consolidate all my sites onto that system (right now my sites are spread across three different hosts).

Some observations after a couple weeks on the Slice:

  • 64-bit OS memory usage makes a large amount of RAM important, especially when running Drupal or another CMS with relatively high memory usage.
  • Even with a bunch of optimizations (like using the Boost module or a reverse-proxy http cache), a 256MB slice can feel very limiting—and that's with just one site running.
  • Unless you want to become a bit of a Linux sysadmin (or at least become familiar with the CLI), don't get a slice or linode, or anything of the sort.
  • Slices are more for fun and learning (at least on the low end) than for heavy-hitting high-traffic sites... imo.

Since we're moving again, please pardon the dust. In addition, in reference to this forum topic, I'll be merging Articles and Blogs (eek!) and working to streamline the posting process.

No votes yet

Comments

michaelsbradleyjr's picture

I'm certainly biased ;-) but it is possible to run heavy-duty production sites and services on everything from a single smaller linode or slice to multi-tiered, multi-VPS setups (load balancing, failover).

I think you've "hit the nail on the head" as to the reasons that an unmanaged VPS is not a good solution for some folks:

(1) If you're trying to learn your way through the Linux sysadmin side while also trying to get real work done on the dev side (i.e. to roll out a production site), you're likely headed for frustration if not disappointment. It's probably better to use something like vmware or virtualbox on your local computer to learn your way around a Linux (or BSD) system before you move on to paying for a VPS in the cloud. In the meantime, use a shared hosting environment or something along those lines to relieve you of the sysadmin burden and get on with what you do well, e.g. Drupal or Rails or whatever.

(2) It's quite possible to setup a small VPS (~256 MB RAM) to host a CMS or some other web app even for a decent sized site. This requires some creativity, some know-how, and a willingness to do things like drop apache and adopt nginx or lighttpd -- with Rails, Drupal etc. running behind the lightweight proxy via fastcgi or whatever. But now we're back to the problem of experience and knowledge on the sysadmin side.

Lehti's picture

Is drupal any lighter or requires less memory or processor than wordpress? I have heard that it is a real pain in the a** to manage a popular site that is built with wordpress altough some big sites use it (techcrunch). I wonder if drupal is better with big sites and high daily traffic. I could never manage a VPS or anything like that so I will only build smaller sites that are more focused to only one subject or niche so that I can always be on reseller account or shared hosting account. Maybe one day my some of my small sites will grow too big and I have to have a separate rack server. But then I can easily buy the hosting and manage cause traffic means money if you monetize the right way -lehti :)

oscatholic's picture

Not particularly, especially if you add a ton of modules. This site uses something like 60 modules in all, and if I ran the site without caching, I could probably only get a few hits per second. However, I use static html caching for most everything these days, which means the server often doesn't have to do any processing to serve up a page request, meaning it can handle at least a few hundred page requests per second!

WordPress has a similar plugin to Drupal's boost, which builds this cache. If you're going to have more than a little traffic, you're really going to want one of these plugins!

Advancing the faith.

Post new comment

The content of this field is kept private and will not be shown publicly.