caching
Looking for ideas for version 2.0 of Boost
Boost is nearing RC 3, and my estimate is the release after this will be 1.0. As such I'm looking for ideas for the next version, 2.0.
Project Mercury: PressFlow Drupal+Varnish AMI Alpha4 Release
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.
Project Mercury: Pre-configured Drupal+Varnish AMI
Inspired by my own work over the past year with Amazon EC2 and this great post from Eric Hammond at Alestic on how to bundle public AMIs, today I released my first public machine image. I call the project "mercury," and the goal is to combine the power of Varnish and Pressflow Drupal in one easy-to-run package.
Why is this important? Because Varnish fills the same role as the Boost module, except it can handle 1000s of requests per second. Your constrained resources are going to be network and bandwidth. Getting it working well takes a bit of doing, but thanks to PressFlow and support from davidstrauss and DamZ, I've gotten a vanilla system working.
Best method of caching complex data generated from nodes?
Not sure if the title is good enough to describe this problem, but here goes...
I've had some small input into the KML module (http://drupal.org/project/kml). This generates KML (Google Earth) files which show placemarks for content with locations. While rather cool this can be very slow when you have many nodes with location information.
Drupal Authenticated User Scalability
Overview: Drupal Authenticated User Scalability
New module: Authenticated User Page Caching (Authcache)
Authcache offers page caching for logged-in authenticated users. This allows Drupal to load pages in 1-2 milliseconds and take the load off the the database & processor. Please help test this module (the site I was creating this for got axed, but I continued development on this module). Feedback & patches are welcome. This module can be used for anonymous users (it's faster than Drupal core since the database won't be hit), supports the statistics module, and can cache blocks of user-customized content.
Many thanks to Steve Rude for his work on the Cache Router module, which Authcache uses as its caching system.
This is how it works:
Getting cache tables out of DB (or into different DB)?
Hi All,
What (if any) best practices are there for achieving a configuration where the cache tables aren't writing to the default DB?
My specific concern is related to http://groups.drupal.org/node/12890 (MySQL Binary Logs of Death). Would like to write the cache mutator statements to a different DB so they aren't included in the binary log.
We're running 6.8. Using APC for opcode cache.
It seems like the options are:
- set different DB/tables in place of cache.inc. Specifics?
- use Cache Router. Specifics?
- use Memcache.
Utilizing Multiple Caching Strategies?
Last night I (finally) updated my (ultra-simple) personal website to 6.0, and while I was at it I decided to try out some caching ideas that had been brewing in the back of my mind for a while.
Though all caching strategies have their pitfalls and drawbacks, the idea I wanted to try -- combining Boost and Memcache -- seems like a real live-wire. However, if it can be made to work, I think it might offer some significant advantages.
Tutorials: Drupal caching, speed and performance
To make it easier to find information on these matters, I've started the new handbook page Drupal caching, speed and performance in the Tutorials section of drupal.org. It's just a guide to information and tutorials on optimizing Drupal's performance, speed, and scalability, with an initial listing of fourteen resources. If anything is missing, you may edit it to add other useful Drupal performance resources.
Staying online during a perfect storm of traffic
As seen on Planet Drupal, the recent article Improving Drupal's Performance with the Boost Module for the UN's Millennium Campaign (October 23rd, 2008) describes how a Drupal site successfully managed a very high traffic situation. They achieved this with "one enormously helpful Drupal module, called Boost", and "some fine tuning".







