Nginx Cache Sprint at Drupalcon London

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
perusio's picture
Start: 
2011-08-26 11:00 - 18:00 Europe/London
Organizers: 
Event type: 
Sprint

Nginx has 2 caches:

  1. A proxy cache when you're proxying to another HTTP server.

  2. A fastcgi cache when you're "proxying" to FastCGI.

This is a native cache not an external one. Hence you can get high performance caching without the additional complexity of having another moving part on your setup. Thus making potentially making things like Varnish superfluous.

The issue is that there's no cache internal state register. You can purge a page or the all cache. It's impossible to implement wildcard clearing in DrupalCacheInterface terms. We need a way to keep that state.

I gave some thought to the issue and I have some ideas on the direction but a lot is still open for discussion.

If you're at Drupalcon London and are interested in contributing to this project show up tomorrow at Fairfield Halls for the sprint. This project has the potential to be the one drupal external cache to rule them all.

Comments

I am using Nginx speed

zkrebs's picture

I am using Nginx speed booster from BOA (Barracuda Octopus Aegir) and I could really use this! Awesome.

Didn't see this post until I

jcisio's picture

Didn't see this post until I left London :(

Hi! I was attending a

Coornail's picture

Hi!

I was attending a different codespring, but I'm very interested in the results!
Is there any code available? Can we help with something?

I'm afraid not much :(

perusio's picture

The sprint was hijacked by discussions on architectures using Nginx as an "application server". Right now the main issue is getting the wildcard option of the clear method of DrupalCacheInterface to work. Ngixnx cache doesn't keep state and the current 3rd party module doesn't provide a wildcard option for purging. Things to research:

  1. Does it really matter the wildcard option on the get method?

  2. If the answer to 1 is yes then we simplify things immensely. When updating a piece of content we just hit that URI with an header:
    X-Accel-Expires: 0 and to be on the safe side (try to) purge it.

  3. If The answer to 1 is negative, .i.e., the wildcard options really does matter, then we need to keep state in some way and proceed from there.

So the main issue right now is:

Do we really need the wilcard option of the clear method?