CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site

This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Installing CiviCRM »
  • Drupal Installations (Moderator: Piotr Szotkowski) »
  • Project Mercury?
Pages: [1]

Author Topic: Project Mercury?  (Read 3240 times)

pbarmak

  • I post occasionally
  • **
  • Posts: 111
  • Karma: 3
  • CiviCRM version: 3.3.5
  • CMS version: Pressflow 6.19
  • MySQL version: 5.1
  • PHP version: 5.2.10
Project Mercury?
June 23, 2010, 05:44:54 am
I was wondering if anyone has been running Civi on the Project Mercury stack: http://getpantheon.com/mercury/what-is-mercury

It's basically Pressflow + Varnish + a bunch of other performance improvements.  But I'm wondering how well it works with Civi and if there is enough of a performance gain that it's worth the extra complexity in the installation/maintenance.  I'm running a relatively small site - maybe 20 users (10 concurrent) with 30k+ contacts.  In my small tests, the Mercury stack definitely seems snappier, but I haven't tried it on a full-scale site yet.

If anyone has any experience and can share opinions (even on Pressflow + Varnish alone), I'd appreciate it.  Thanks.

rcrusoe

  • Guest
Re: Project Mercury?
June 23, 2010, 09:30:29 am
Can you share any of the additional details on the testing you've already done, such as server hw and os, etc? Also, are you running Civi on that already as well? Project Mercury is very interesting stuff, and certainly might be helpful given some of the flack that drupal, and drupal/civi sometimes receive about performance. I was planning to do a little test installation including Civi on a spare dev box running ubuntu server but won't get to it for a couple of weeks, probably.
Howard J

pbarmak

  • I post occasionally
  • **
  • Posts: 111
  • Karma: 3
  • CiviCRM version: 3.3.5
  • CMS version: Pressflow 6.19
  • MySQL version: 5.1
  • PHP version: 5.2.10
Re: Project Mercury?
June 23, 2010, 11:50:55 am
Howard,
OK, this may be long, but here goes some details :)

First, based on my limited Civi experience, I have to agree with the flack - just based on my simple timings, I can see that Civi has a lot going on in the background and pages returned aren't as small as some might suggest (so bandwidth and physical location of the server to where most folks work is important).  Here are some details on what I've done so far with hosting:

Tools: I keep things simple, I test timing of page loads and pages sizes using Firebug with the Net plugin and the YSlow plugin (which gives me good info on page sizes with and without caching, plus detailed load times).  Please keep in mind I didn't run any official test suites or automated page tests or anything like that - mostly eye-balling with these tools (it wasn't hard to see the speed difference on different hosting solutions).

For all the tests, I tried to stick with 32bit Ubuntu 9.10 as that is what Mercury uses in their AMI/script.

First Test: Shared Hosting
I installed a standard set of Drupal 6.17 plus Civi 3.1.5 on 3 different shared hosting plans: hostgator, hostmonster, and 1and1.  Without getting into specifics on which host was better/worse, none of these options are something I would use or recommend for a production site, even for the size I'm dealing with (20-some users, 30k+ contacts, etc - relatively small to medium sized implementation).  I'm honestly not sure how anyone is successfully running a production site on these shared hosts - maybe I've just had bad luck or something, but I get very inconsistent results.

Some shared hosting providers have way too many accounts on a single small box, so I'll see heavy uptime stats on the box even when I'm not running anything.  That leads to inconsistent performance - sometimes pages come up within 3 seconds, sometimes it's 10-15 ... just not a good experience.  And nothing seems snappy with shared hosting - lots of lag between clicks (like on the contact page with all the tabs).  And then, of course, all the issues with php memory limits, yada yada ... not worth it.

Second Test: Amazon EC2
I've used EC2 for other projects (data warehousing, hadoop, etc), so it was easy enough to set up an instance.  And I found Project Mercury when searching for an EC2 AMI with Drupal.  They have two different AMIs (one for a 32bit "small" instance, and one for 64bit "large").  I went with the small instance (on the West Coast servers since I'm in WA) using their AMI - very simple, very fast to setup.  The performance was simply amazing compared to shared hosting - felt almost like I had a local box within our network - very snappy feel.  Timing on almost all Civi pages (forms, reports, whatever) were around 1-1.3 seconds per full page load.  Now this was using Mercury (which is really Pressflow plus Varnish plus memcached) out-of-the-box.  I didn't modify anything, just added civicrm to the modules as usual.

Note: Setting up Civi on top of Mercury is just like setting it up on vanilla Drupal (because Pressflow is just like standard Drupal).  You run through the normal installation routine, no changes/tweaking needed.  And, so far, I haven't seen any issues running Civi with Mercury/Pressflow - functionality seems to be the same across the board, haven't seen a bug yet.  If anyone else has issues, please let me know before I proceed down this path for production!

Third Test: VPS
So I wanted to see if it was EC2 hardware being so solid or Mercury itself or a combination.  So I setup with 2 different VPS hosts: Server Axis and Linode.com, both with 512MB RAM packages (the minimum for Mercury and what most people on these forums say is enough RAM - for production, I'm going to bump the RAM to be safe).

The first thing I learned was having the server physically located closest to where most people would be working is a big plus (not sure most people mention this, but it proved important to me).  Server Axis was significantly slower and had more lagging than Linode, and I believe some of that was due to Linode having a datacenter in CA, much closer to me (ping times were averaging 56ms on Linode vs 120ms on ServerAxis, not a huge deal, but just kinda tipped me off).  So, on Linode, I did three tests:
1. Mercury stack (full stack) + Civi (just like EC2).  Note: Linode has a StackScript for Mercury, so it does the full painful setup for you!
2. Only Pressflow + Civi
3. Vanilla Drupal + Civi

All three used the same 128M php memory limit setting.  I'm still testing all of these out.  So far, the EC2 instance still stands as the snappiest, but it's also the bigger server (I only got the smallest Linode package for testing - 512MB RAM vs 1.2GB on EC2, I think) ... and EC2 is possibly more expensive (though I haven't seen real numbers on that yet).

Of all three Linode tests I did, I saw pretty similar performance for Mercury vs Pressflow alone - page loads were close to EC2 (1-1.7seconds for a full page load) and clicking around the site seemed quick in comparison to any shared hosting.  They both beat out Vanilla Drupal (not by much, but it was noticeable and I'm betting will be more so as we scale to more concurrent users).

The full Mercury stack may actually be a better long-term option once I get more concurrent users and scale the DB to more contacts.  But it comes at the price of a more complex setup and maintenance, something I'm not sure is worth it for the size of our organization.  I probably don't need some of the services it comes with (like Apache Solr search engine), so I'm thinking of going with Pressflow and then looking into setting up Varnish by hand to see if that helps.  Either way, it seems we definitely want some kind of caching on Drupal and having Pressflow helps as it also optimizes some of the DB calls from what I've read.

That's where I'm at so far.  At this point, I'm very happy with Linode.  They also have a scheduled backup solution now (full filesystem snapshot, though it's local, not off-site as I would prefer) for an extra few bucks, which I think is a nice plus (feels like an AMI for EC2 - can quickly get another instance going).

Hope that helps.  I sure would love to hear from others who might have tried Mercury to see if it's worth sticking with that.  For now, it seems to be a solid option, though maybe a tad overkill for my needs.

Paul

gregcoit

  • Guest
Re: Project Mercury?
July 13, 2010, 04:09:49 pm
Mercury 1.1 (in Beta) has the ability to turn off services you don't need, including apache solr (via the tomcat service).

Hope this helps,

Greg
--
Greg Coit
Systems Administrator
http://www.chapterthree.com

xavier

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4453
  • Karma: 161
    • Tech To The People
  • CiviCRM version: yes probably
  • CMS version: drupal
Re: Project Mercury?
July 13, 2010, 11:30:38 pm
Hi,

I'd consider a lot of small improvements before going that way:

For what I read, having a nginx or lighttpd+ fastcgi is going to get you the same benefit of varnish, and probably better as you have more memory for something else.

Tune mysql to give it enough memory

Use php-cli for the crons with a nice -19  (on 3.2)

Have a light theme, without too many modules enabled.

Put it in a location less than 30ms away of your users.

And use memcache configuration on civicrm.

This being said, you should properly benchmark and stress load, everything is pretty snappy when you are the only one using it ;)
-Hackathon and data journalism about the European parliament 24-26 jan. Watch out the result

pbarmak

  • I post occasionally
  • **
  • Posts: 111
  • Karma: 3
  • CiviCRM version: 3.3.5
  • CMS version: Pressflow 6.19
  • MySQL version: 5.1
  • PHP version: 5.2.10
Re: Project Mercury?
July 26, 2010, 03:56:40 pm
xavier,
What you point out makes sense as a first step.  Do you have any quick tips/pointers to the items you brought up?

What MySQL tuning would you consider?  What my.conf settings should be looked into and at which values (roughly speaking)?

How do we set up memache on civicrm?  Is it just setting up the PHP memcache?

What do you recommend for caching: nginx or lighthttpd?

Thanks.

TwoMice

  • I post frequently
  • ***
  • Posts: 214
  • Karma: 16
    • Emphanos
  • CiviCRM version: Always current stable version
  • CMS version: Drupal 7
Re: Project Mercury?
July 26, 2010, 05:37:21 pm
Ditto on the questions from pbarmak. Performance is a bit of a worry for me as we launch our first Civi installation.   I'd really love to hear some straightforward configuration tips.
Please consider contributing to help improve CiviCRM with the Make it Happen! initiative.

xavier

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4453
  • Karma: 161
    • Tech To The People
  • CiviCRM version: yes probably
  • CMS version: drupal
Re: Project Mercury?
July 29, 2010, 08:10:22 pm
hi,

well sysadmin and tuning is complicated and the right values depends of your hardware.

If you have a dedicated server, that's probably, no matter the tuning, good enough, unless you got zillions of contacts and users.

Do some load testing, you will see when the problems comes. Hopefully in a higher load that you will ever experience with real users.

Nothing concrete I'm afraid, beside hiring a sysadmin to do the tuning for you and run tests.
-Hackathon and data journalism about the European parliament 24-26 jan. Watch out the result

pbarmak

  • I post occasionally
  • **
  • Posts: 111
  • Karma: 3
  • CiviCRM version: 3.3.5
  • CMS version: Pressflow 6.19
  • MySQL version: 5.1
  • PHP version: 5.2.10
Re: Project Mercury?
July 30, 2010, 05:40:07 pm
I use a Linode 1024 VPS (which I would think is plenty, even with load) and have done some tuning of MySQL on it.  I can tell you that even with this type of VPS, in close proximity to users, there is still a bit of a lag compared to using something like Mercury on Amazon EC2.  That may be due to EC2's disk layout or it may be Mercury, I can't tell just yet.

Also, I would think that having some kind of caching/accelerator on the PHP side is a good idea no matter what system is used.  I looked into eAccelerator today and followed a basic install I found here.  I haven't had enough time to test it, but so far, things definitely feel snappier and load times (using YSlow) are faster.  I'm not sure how much of an improvement it is over Varnish (or Varnish plus eAccelerator), but thought I'd let folks know in case they want to try it out.

At this point, with about 20k contacts imported and pretty much only myself on the system, with Pressflow, I'm seeing page loads hitting around 1.4-2 seconds total (depending on the page).  Still feels a bit slower than I'd like - I'd love to know what others are getting.

I'll reply again once I test more and share my my.conf settings in case it helps anyone else.

Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Installing CiviCRM »
  • Drupal Installations (Moderator: Piotr Szotkowski) »
  • Project Mercury?

This forum was archived on 2017-11-26.