Exove Ltd is developing a new module, integrating Varnish into Drupal in a way that allows caching not only anonymous users' content, but authenticated users' content as well.
The basic idea behind the module is to generate cacheable anonymous versions from any page with cacheable content, leaving placeholders in place of user specific content, and to serve those versions to all users. Any user-specific content is then replaced with AJAX for all authenticated users.
This module is designed to be used on sites where there are a lot of simultaneous authenticated users, and where caching the content just for the anonymous users isn't enough. Custom code is required to let Cache Control know what content is cacheable and how it should be replaced.
Early versions of the module are already in production use, but the current version at Drupal.org is a work-in-progress; we're actively developing the module to respond to needs by other customers. The module can be currently found in its sandbox here: http://drupal.org/node/1138426/ , and the project approval issue here: http://drupal.org/node/1155312 . The module repository includes an example module that shows how Cache Control can be integrated.
Any comments or feedback are welcome.
Comments
Check also ESI with varnish option
Topic is here - http://groups.drupal.org/node/50093
ESI
+1 on ESI, if you are expending effort in this area it would be great if you could add to the existing work.
http://drupal.org/project/esi
How Cache Control differs from ESI
(Pasted from newly edited project page)
A page with ESI blocks needs to be fully compiled before it can be shown to the user. If just one of the requests fetching user-specific content hangs, the whole page is waiting for that one block. With cache control, most of the page is available as soon as Varnish returns the anonymous version, and the user-specific content is added once it's ready.
The ESI module currently supports block content only. Cache Control allows you to cache any content for registered users, although it does require that you write custom code in your own modules in order to do that.
In case of pages that have a large number of user-specific blocks, ESI makes as many requests to Drupal (assuming none of the user-specific blocks are cached) as there are blocks. Cache Control makes one (or two, in case there is both user- and role-specific content). Even if the ESI-blocks are in Drupal's cache, bootstrapping Drupal is hard work for the server.
The philosophy behind Cache Control tries to keep as much code as possible on the Drupal side. After all, there are a lot more people that can do Drupal than people that can do vcl. We try to keep the vcl configuration unchanging and as simple as possible. Any new things should require changes on the Drupal side only.
Cache Control should be usable with any reverse proxy, not just Varnish. It hasn't been tested with anything else yet, but the architecture doesn't depend on anything Varnish-specific.
See also http://drupal.org/node/1155312#comment-4501264