Amazon Web Services (S3, EC2)

Mercury 0.71-Beta has been released with small bugfixes (see https://bugs.launchpad.net/projectmercury for details).

AMI IDs are:

US 32-bit: ami-bd7c9fd4 - chapter3-storage/PANTHEON-pressflow-mercury-0.71-Beta.manifest.xml
US 64-bit: ami-b17c9fd8 - chapter3-storage/PANTHEON-pressflow-mercury64-0.71-Beta.manifest.xml
EU 32-bit: ami-8f2c07fb - chapter3-storage-europe/PANTHEON-pressflow-mercury-0.71-Beta.manifest.xml
EU 64-bit: ami-73230807 - chapter3-storage-europe/PANTHEON-pressflow-mercury64-0.71-Beta.manifest.xml

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.

Just wanted to let everyone know we're hard at work on a Beta release of Project Mercury. Currently we are tuning Varnish further, working to package Apache Solr on board as the search backend, and testing the whole system for bugs. We will likely issue one more alpha release (0.6) before we get to a Beta, but I want to have that launch by the end of the month if possible.

The high level road map:

• Package Solr
• Improve default Varnish config
• Thoroughly document "putting your site on mercury"
• Resolve lingering bugs (e.g. cron.php issues)

Once we hit Beta we'll be pushing for wider adoption, which means pursuing alternate non-Amazon hosting options. Currently we're looking at alternate cloud providers, VPS partnerships, and other packaging options like VM images, etc. So stay tuned, and let us know what else you'd like to see us look at including early in the Beta cycle!

Hi,

In trying to take the Pantheon Aegir AMI for a spin, I hit my first obstacle with the database settings during the install.

This may be very obvious beginner mysql mistake but do I need to create the database, user and password before attempting the install?

I tried logging into mysql to create a database and set it up but realised that nowhere in the basic documentation does it mention the mysql password.
I tried the usual suspects , leaving it blank, drupal, mysql, root but none seem to work. I should mention I am trying to login as "root".

Hi,

I was wondering if there is one consolidated set of instructions anywhere that deals with how to set your own drupal based site over the base pressflow site launched over your EC2 mercury instance?

Basically I would like to know more about the following steps.These seem to be covered in the www.getpantheon.com intro video but the section is sped up and very difficult to try and dissect to understand what is going on.

I have successfully launched a small instance running the Mercury AMI. I am able to login to pressflow and have root access via SSH to the EC2 box.

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.

Today I'm glad to announce the latest release in this line of AMI development. This update solves a number of issues and moves us one step closer to a sable beta release. The current AMI ID is ami-c353b2aa, and you can find this AMI by searching for "chapter3" or "mercury" in your AWS console.

For more background information about this project, see my initial g.d.o post and my blog post announcing the initial release.

Below you will find the notes for this release. Also in this post I will include a development roadmap, as well as some more explicit explanation of the techniques I'm using for making the AMI work out of the box.