varnish

I just installed Mercury on Linode server, but Varnish doesn't cache pages on site I transferred there.

Steps I did during site transfer:
- copied modules and themes
- copied files
- imported database (didn't change settings.php as I used same database as in settings.php)
- run update.php
- enabled Varnish, Cookie cache bypass modules

Varnish keeps on crashing on me, and since I have authcache and only one server, I'd rather not deal with it.

I removed it by apt-get remove varnish, and setting apache to port 80. Are there any other steps that I need to take to set the server to be like no varnish? What about the memory allocated to varnish in the bootscript, is that someone I'll need to clawback?

Thanks.

I want to give everyone a preview of what we're working on for Mercury 1.1:

<

table id="Table_01" style="height: 602px; width: 630px;" border="0" cellpadding="0" cellspacing="0">

<

blockquote>

Announcing Wild Pockets Gallery Beta

Over the past few days some of us have been discussing the aims and ambitions of this project:

http://drupal.org/project/esi

There are a lot of pieces to be developed to support this properly. My aim is to get something simple in place to allow blocks, regions and panels to be served out of an ESI cache. There are further ideas to build some sort of ESI-assembly into the Boost module, and to implement an intermediary cache layer between Drupal and an external ESI cache (e.g. Varnish) to prevent multiple bootstraps.

So, let's take this discussion out to the wider community!

I'm having trouble with a Pressflow install and its lazy session handling.

The issue
Anonymous page views are still getting a session cookie and thus the Cache-Control:max-age header is being set to 0, making it difficult to have Varnish cache pages.

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

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.

mikeytown2 and I hijacked my nginx built-in caching thread for some benchmarking discussions. Mostly Boost vs Varnish vs. Nginx caching. It needs its own thread.

My quick and dirty ab testing on my home "dedicated" server is at http://groups.drupal.org/node/26485#comment-101296 with a couple more using keepalives is at http://groups.drupal.org/node/26485#comment-101518.