Mercury

I've been working on better integration with EC2 user-data for Project Mercury. The goal is to allow users to specify configuration options when they launch a Mercury instance to simplify the process of manual configuration.

For example if you'd like the EC2 instance to receive an Elastic IP address you'd specify:
IP="new"
Or an existing elastic IP address:
IP="123.123.123.123"

With great pride, and after six alpha-level releases, I'm announcing of our seventh iteration on the Project Mercury stack, finally baked enough to call "beta".

At this point, we know that many people are using the Mercury EC2 image in production environments, and we've tuned this release conservatively to prevent it from breaking down under heavy load. We've also verified that the stack will work under a resource-constrained VPS (e.g. one with 1/4th the RAM of a small EC2 image), which gives us more confident that this configuration is stable. We also have a kickass logo:

My name is Greg Coit, sysadmin for Chapter 3 and I've been helping with Mercury development and testing.

We wanted a get a quick idea of how hard we could push mercury under more "real world" circumstances, so I combined siege and ab to generate a broad spectrum of hits. ab (short for apache benchmark and part of the apache2-utils package) allows you to generate a very large number of hits on one url, while siege (a perl script which comes in a self-titled debian/ubuntu package) lets you spread the hits across many urls, most of which won't be cached. This mixed-load is a much more nuanced and accurate way of looking at performance than peak throughput on a single url.

Just a heads up; as we move towards more and more stable builds of the Mercury stack, we are starting to look at deploying it on other infrastructure besides EC2. This week, we set it up and tuned for a modest (512MB of ram) VPS. These tests were successful. We were able to simulate a mix of non-cached traffic along side the simple ApacheBench battering, and the system held up well, even without gigabytes of ram to support it.

Hi all,

Is anyone using Vulcan? I've installed the EC2 instance, but can't find any documentation on configuration for selenium, hudson, etc. I've used selenium on our other boxes before so I'm familiar with that.

What is packaged into the Vulcan instance? Is the server just a skeleton or are there packages set up already? Is this ready to go or just an instance I'd build manually? What are the advantage to using the Vulcan EC2 instance?

Thanks

Can the maintainers of the pantheon AMIs please update the Aegir AMIs?

I'm quite eager to use it, but would like it to be using the latest version please.

Thanks!

In certain instances I see the next error (which I remember vagually seeing in drupal.org.il)
Error 503 Service Unavailable
Service Unavailable
Guru Meditation:
XID: 1525473736
From googlin' i understand that this is apache not responding to varnish, Is this correct?

How do I play with the time varnish gives apache to respond?
best regards
Lior

I just wanted to post an announcement that we've finally gotten out a point-update of the Project Mercury AMI. Just in case you were wondering if this project would continue, it will! I've been really excited and encouraged by all the positive feedback so far, so keep your ideas and questions coming. The 0.51-Alpha release includes a number of bugfixes and improvements, most notably it:

• Is based on the latest Pressflow including Drupal Core 6.14 and Simpletest 2.9
• Fixes the self-update process to merge correctly and pull from Pressflow's lovely new VCS home on Launchpad
• Includes the rc1 version of cacherouter
• Fixes postfix and s3 metadata issues so there's now a working MTA out of the box

Most importantly for people considering this stack for production deployments, we're now bundling 64-bit images with every release. The quickest way to find the AMIs is to keyword search for "mercury" in your favorite EC2 console. More information and AMI ids are below the fold. Let me know what you think, and what you'd like to see next!

While working through some issues this weekend and preparing another blog post, I finally got around to doing some comprehensive benchmarking on Project Mercury. In the process, I discovered that the first bottleneck I hit running tests from my desktop was the local (last-mile) internet connection, so I switched to running the tests from another EC2 instance. This means that network is not a factor in my results, giving us a real sense of the raw power behind this stack.

For all these tests, I used the Mercury Alpha4 release on a small ec2 instance, loading a staging copy of Mission Bicycles, which is a good "heavy" example in that it has a lot of modules loaded, including Ubercart and Panels. My goal was to measure throughput and response times under various caching configurations, angling for the best results in terms of pages served per second, and delivery time.

I started by cutting things all the way back to nothing, and then added each layer of the caching infrastructure, running benchmarks at each point. The results are quite eye-opening. Can you say 2000+ requests per second? Read on for the full story.