Advice needed for performance on a VPS...

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Train's picture

I work for a web design company and part of our service is hosting for our clients. We buy hosting in the form of VPS accounts and put a certain number of clients on each account depending on their usage and the 'size' of the VPS.

For example, I have one VPS that has 1G of RAM and 32 cores and I run 12 sites each in their own cPanel, each with bandwidth anywhere from nothing to (at peak) 130G/month. I have another VPS with 5G of RAM, 16 cores and almost 50 sites with usage from nothing to 65G for a couple of them.

So I have a mix of sites with a variety of usage and I try to balance across the VPS accounts by limiting the number of large accounts I put on them. I need to reduce the load on these servers in order to provide better service and make the most of our investment.

The two obvious choices I have found would be Varnish and Memcache(d). I have checked with my providers and I can install these (APC maybe not because of SuPHP).

But... what about memory usage? The rule of thumb is 25% of your available RAM for these services, does that mean I would need to commit 50% of my RAM to them or 25% total? Wouldn't I be starving my service of RAM? And what about having so many sites on the server? Wouldn't Varnish and Memcache(d) want even more RAM to be effective?

There also are performance options available to me I could make use of, such ad multi-site and a CDN...

Thanks.

Comments

I don't know what SuPHP is,

Garrett Albright's picture

I don't know what SuPHP is, but if it's preventing you from using APC or some other opcode cache, figure out why and fix that. Opcode caches are relatively simple to set up and will deliver a lot of bang for your buck in terms of set-up time and server resources. If you can combine the sites into a multisite so that the opcode cache only has to cache one copy of Drupal core and common contrib modules' files instead of one per site, even better.

Seeing as how you're hosting several different types of sites with (I presume) different usage patterns, Varnish may be a bit more difficult to configure; a configuration which works great on mostly static sites won't work great for highly interactive ones and so on.

If it's not strictly necessary, I'd consider ditching cPanel and just learning how to administer the site using the command line. You'll save RAM and resources that cPanel would otherwise occupy, not to mention the cPanel licensing fees if you're paying those directly.

If you can combine the sites

dalin's picture

If you can combine the sites into a multisite so that the opcode cache only has to cache one copy of Drupal core and common contrib modules' files instead of one per site, even better.

But the trade-off for that is a maintenance nightmare. I wouldn't advise that route.

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

Wouldn't multi-site reduce

Train's picture

Wouldn't multi-site reduce maintenance by having one code base? I'm confused...

It depends on the kind of

tripper54's picture

It depends on the kind of sites you're building. The maintenance issue comes with the fact that all the sites share the same code base. So therefore if you change any code on one site, you're changing code on all the sites. The whole setup can become quite brittle.

If your sites are a cookie cutter style site (common features, templates etc), then that might not be too much of a problem. In my experience though even if sites start out that way they tend to diverge over time as site owners request additions and changes. Opinions are divided on this, but I tend to avoid multisite even if it seems like a good idea at the start of a project.

As far as multisite reducing maintenance, I guess it shaves a bit of time off updates. But the majority of update time is spent testing, and multisite does not avoid that.

If you're not hacking core or

Garrett Albright's picture

If you're not hacking core or contrib modules, I'm not sure what the problem would be either. At my first Drupal gig, we hosted most of our client sites this way, and I can't recall it being a "maintenance nightmare." dalin, care to elaborate?

Let's say you've got a

dalin's picture

Let's say you've got a multi-site setup running 50 sites and it's time to run a security update for module X. It requires a DB update so first you have to find a way to script drush updatedb for the 50 sites. But in your testing you find there's an issue on site #24. Now what do you do? Do you hold up the security update for the other 49 sites? Or in another scenario site #37 wants to install module Y which requires module X version 3.x but the rest of your sites are running 2.x.

In both scenarios you can put a site-specific version of a module in sites/[site]/modules/contrib/ and not effect the other sites. But it you do that too many times you've suddenly got a mess of different versions of the same module all over the place.

It all depends how cookie-cutter these sites are. If they're all exactly the same, just a different theme for each one then sure go for it. But it sounds like the OP has a wide variety of different sites.

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

It's possible to manage this

jdidelet's picture

It's possible to manage this if you've managing the common code with git tagging strategy (or create an installation profile if you want).
With that, you can install your common code in different www root folder for each different version (www-root/drupal/7.26.1/... www-root/drupal/7.26.2 ...) and just use symbolic links to link on your specific websites folder.
In my example, www-root/drupal/7.26.1/sites/ or www-root/drupal/7.26.2/sites will includes a list of symlinks pointing to your website-folder.
After, you juste have to update you root directory in Apache or Nginx to redirect the websites you wants to manage to the proper version (and reload config). And if need, keep some website to the old one version if needed because you have compatibility problem.
You can even create batch with Drush and Drush Make to update automatically everything.


Julien Didelet
Founder
Weblaa.com

Why to reinvent the wheel? In

omega8cc's picture

Why to reinvent the wheel? In Aegir with just two clicks you run the mass migrate for all sites sharing the same code base (platform) to updated code base (platform) and if it fails with any site or sites, they are automatically reverted back to the old code base while all the other are migrated automatically. Then you are free to debug the failed upgrades and try the migrate again for the remaining sites. And if any site diverges with custom code, you create a separate code base for them. Why to complicate things already made childishly simple by the community?

Wouldn't multi-site reduce

Train's picture

Double post?

SuPHP works with Apache so

Train's picture

SuPHP works with Apache so that PHP scripts are run under the permissions of the script owner, from what I understand. I'm not sure why this would prevent me from running any sort of opcode cache or perhaps there's an alternative available... I'll check with my providers.

We use cPanel because it comes with the hosting and is easy enough that I can set one of my developers to launching a site without having to train them on a Linux CLI.

We build off of a 'template' site we built, so we probably have enough simple, mostly static sites that are similar enough that we could aggregate into multisite or at least one set of Varnish/Memcache settings to make it worth our while.

My big concern here is the memory consumption of Varnish and Memcache. With a limited amount of RAM available, don't I run the risk of squeezing out Drupal?

To follow up on my own post,

Train's picture

To follow up on my own post, from what I've garnered you can't use an opcode cache with SuPHP because it destroys the PHP instance after it's been used. Therefor any caching goes away with it. FastCGI doesn't do this and can caching can be used effectively.

We use cPanel because it

Garrett Albright's picture

We use cPanel because it comes with the hosting and is easy enough that I can set one of my developers to launching a site without having to train them on a Linux CLI.

Wait, your developers insist on using cPanel instead of a CLI?

I wouldn't hire a developer that couldn't use a Unix CLI (if I were in a position of making hiring decisions). That doesn't inspire much confidence in their skills.

Have you considered ditching

tripper54's picture

Have you considered ditching your cpanel setup for BOA? With that many sites it might provide an easier way to manage them, and BOA is nicely optimised for drupal.

BOA as in

Train's picture

BOA as in Barracuda/Octopus/Aegir? I'd be willing to look into it but a goal of mine is to not spend time managing servers. Our core competency is developing Drupal sites, not managing servers.

I'm trying to figure out how to not keep throwing horsepower after Drupal performance issues. Varnish and Memcache(d) seem to go a long way towards that, it's just a matter of what resources they will require.

In the very least I'm implementing Boost for everybody and adding a CDN to the larger sites in addition.

That is exactly what BOA is

omega8cc's picture

That is exactly what BOA is for - to automate managing your high performance vps or multiple vps systems and never do it manually again. Just try it out!

I'm trying to figure out how

gchaix's picture

I'm trying to figure out how to not keep throwing horsepower after Drupal performance issues. Varnish and Memcache(d) seem to go a long way towards that, it's just a matter of what resources they will require.

Opcode caching with APC is going to buy you more performance gain than Varnish & Memcache. Fix that first. If you can't use APC with SuPHP/mod_php then switch to PHP-FPM. With PHP-FPM you get the security benefit of PHP code user isolation, generally lower memory requirements (since the Apache threads are much smaller and can be done with mod_worker or mod_event), and you get APC.

I'd recommend addressing things in this order:

  1. Change your PHP environment so you can use opcode caching (either by ditching SuPHP or switching to PHP-FPM). If you go the PHP-FPM route, switch Apache to worker or event and disable mod_php.
  2. Enable Memcache. A well-configured memcache will help, especially if you have a lot of logged-in traffic.
  3. Then look at Varnish. I'm a huge Varnish fan, but it may not provide much benefit without a lot of tuning. Plus, Apache running in worker or event instead of prefork can often handle the static content very nearly as quickly as Varnish with less memory overhead. I've heard credible arguments that it can even be faster than Varnish in some use cases (I haven't seen or verified that myself, though).

How about Varnish v Boost?

Train's picture

How about Varnish v Boost?

Boost

wwhurley's picture

I've had bad experiences with Boost related to file system issues. Since it stores cached items as files if you have a large number of them the time to unlink them may exceed the PHP time limit. However, since it also stores state in the database you may end up with inconsistent cache state. Full disclosure, I haven't worked with Boost in some time, so some of these may no longer be valid.

I've used both. It depends

gchaix's picture

I've used both. It depends on the use case. If you're tight on RAM and it's a large site with a lot of logged-in users, Varnish might not be the best choice. If your disk I/O is slow (most VPS systems have lousy disk I/O), Boost may suffer.

Not necessary to use in

jdidelet's picture

Not necessary to use in combinaison varnish and boost. It'snot because you'll put more "performance" tools that means your website will go faster. Keep simple et in regards of what you can do and the context of your project.

If you don't have the control on your vps, you can have boost + APC as basic performance architecture.

If yes, install varnish or nginx in microcaching for first cache level. (I'm excluding load-balancing cache strategy which is another level).
If you can, install a proxy for static content. Not a requirement but useful in any case.
Memcached is great if you can do it but not a requirement.

All depends of how many RAM you have and if you have the knowledge to do it (or want to go deeper in).

OPCACHE is a must, no matter what the control you have on your VPS (if you can't, change it).


Julien Didelet
Founder
Weblaa.com

In your position, my first

tripper54's picture

In your position, my first priority would be getting an opcode cache working. The difference between running drupal with and without opcode caching is night and day - huge speed and memory gains. Is suPHP something that's imposed on you by your hosting provider, or can you choose do turn it off? My understanding is that it is designed for shared hosting so each user runs php under their own user account, for security reasons, aid in tracing abuse etc.

If you're managing all the cpanel accounts under your VPS, I can't see why you would need it.

Host is using SuPHP, but in

Train's picture

Host is using SuPHP, but in one case I can probably get it switched without issue.

My goal here is to optimize performance from these accounts without having to babysit or play sysadmin all day. In the future, if my time is freed up (ha!) on a daily basis I may do something fancy and dive into an EC2/S3/Cloudfront or something and handle these all myself.

Aquia, Pantheon or the Omega people may be a choice in the future, but they're cost prohibitive at this point as a general solution.

For now I have these tasks:
Get opcode cache running
Install Memcache
Implement Boost/Varnish

I may even shuffle some sites around to get similar behaving sites on the same box.

Is there a recommendation for testing tools? Right now I use online speed testing sites to get a handle on it...

Host is using SuPHP, but in

gchaix's picture

Host is using SuPHP, but in one case I can probably get it switched without issue.

I thought this was your VPS? That phrase makes it sound like it's shared hosting.

If it's your VPS, switch to PHP-FPM, turn off mod_php, and enable APC.

If it's not your VPS and is managed by someone else, tell them to fix their PHP setup or find a new provider - no PHP site should ever be run without an opcode cache.

My goal here is to optimize performance from these accounts without having to babysit or play sysadmin all day.

Warning: devops rant incoming ...

If you're hosting production sites for your clients on servers you manage you need to either learn to be a more confident sysadmin, hire someone to do it for you, or get out of the hosting business before you start losing clients because of it.

Managing production servers means you have to babysit them. Configuration management and monitoring tools like Puppet or Chef, Nagios, Monit, and the like can automate most of that babysitting for you, but you need to gather the knowledge and take the time to do the initial setup of the tools and servers correctly in the first place. Otherwise you're going to be playing a constant game of whack-a-mole with infrastructure problems like the one that prompted the original post here. Once the servers are properly configured and the systems are in place to monitor and manage them properly you can spend more time doing the "fancy" stuff you mentioned.

Preach it, brother brother!

Garrett Albright's picture

Preach it, brother brother! Your clients deserve better than half-butted sysadmin.

Automation will save you time and money long term

kiwifellows's picture

Hi,

If you're developing and designing websites and want to offer this service at scale, without the hassle and complexity of maintaining your servers I would recommend this:
-Automate your development so that everything including configuration is in Source Control, preferably something like GIT.
-Remove Cpanel and just have a server that provides web server / db server and any apache modules /memcache etc required.
-Ensure you are using a DNS provider such as CloudFlare so that your DNS is separate from your server (Some WHM/Cpanel installations are really ugly and have DNS hosted on the box - not good practice for high availability).
-design an infrastructure that uses replication at 2 or more distinct data centres.

if you want to offer services like Mail or anything else, I would recommend moving them off your web server and onto

Yes, it is an investment up front of time or paying someone to do it to set everything up right, but the benefits will be quickly realised. It is disciplined because it requires everyone to be on board in your dev team that they follow the same process.

Thanks,

Ben

Automation - further information

kiwifellows's picture

Contact me if you want some further information on how to automate not just your development, but your entire stack (from servers up) so that all developers need to do to deploy is run one single command. It's straight forward once you have everything in place, the first barrier is realising that WHM/Cpanel is not an enterprise toolset and is not going to give you agility when it comes to maintenance and scalability.

cheers,

Ben