RFE: memcached handler to serve cached content

[GoogleCodeExporter]

It would be cool to have a way to cache dinamic content into a memcached
instance and make it available to all your cherokee servers behind a proxy.

Original issue reported on code.google.com by skar...@gmail.com on 12 Dec 2008 at 10:23

[GoogleCodeExporter]

What is the difference with mamecached? Or do you want to reimplement memcached 
as
handler?

Original comment by ste...@konink.de on 13 Dec 2008 at 7:28

• Added labels: Component-Logic, Priority-Low, Usability

[GoogleCodeExporter]

I think the idea is to implement a new handler. It'd be similar to 
handler_file, but instead of reading the file 
content from the file system it'd use a memcache server.

Antonio, is that it?

Original comment by alobbs on 13 Dec 2008 at 7:43

• Changed state: New

[GoogleCodeExporter]

Alvaro, yes, it is... I could be very useful as a dinamic content cache.

Original comment by skar...@gmail.com on 13 Dec 2008 at 9:10

[GoogleCodeExporter]

I support the idea of trying to utilize the power of memcached to help Cherokee
expand both speed wise as well as attractiveness to potential adopters.

Dynamic content might not be the right thing to be stuffing into memcached... 
Static
content certainly could benefit from memcached.

Here's an apache module that ties memcached into Apache 2.2.x:
http://code.google.com/p/modmemcachecache/

Original comment by pubcrawl...@gmail.com on 9 Apr 2009 at 7:10

[GoogleCodeExporter]

Isn't the hole idea of memcached some parts of a dynamic page as static? ;)

Original comment by ste...@konink.de on 9 Apr 2009 at 8:08

[GoogleCodeExporter]

I would like to have a special Header like we have now for X-Sendfile to send 
static
files.
What the Header should do is sending Objects by given key from the Memcache 
Server.
I would like to use it for storing parsed templates into Memcache Server from 
my PHP
Template Engine.
So I could retrieve the cached template via the special Header.

<?php
header('X-Sendcached site1template');
?>

Now cherokee should output the object directly to browser.

Original comment by michael....@gmail.com on 27 May 2009 at 11:09

[GoogleCodeExporter]

Another enhancement would be if there would be a special key naming system
(predictable by requests) so I could set those special keys from the 
application and
cherokee would check first from the request if there is a memcached object. If 
it's
not there call the dynamic script -> the script will store the key and do 
output, so
if it's there cherokee will send the object directly and not call the script.

Original comment by umschlag...@gmail.com on 27 May 2009 at 11:22

[GoogleCodeExporter]

Really useful Web 2.0 features, imho.

Original comment by michael....@gmail.com on 27 May 2009 at 11:48

[GoogleCodeExporter]

For Naming an idea would be.
Storage header
X-Storecached key -> Cherokee will send output and store it in memcache server 
at the
same time

X-Sendcached key -> Take output from memcache server and send it.

Original comment by michael....@gmail.com on 27 May 2009 at 1:36

[GoogleCodeExporter]

I would suggest to actually implement a memcached instead going to memcached.

Original comment by ste...@konink.de on 27 May 2009 at 2:31

[GoogleCodeExporter]

Why reinvent the wheel?
Really not needed....
Makes cherokee code blown up, too.

Original comment by michael....@gmail.com on 27 May 2009 at 2:39

[GoogleCodeExporter]

the iocache is there, and as far as I understood memcached it is a trivial 
store/get
something.

Original comment by ste...@konink.de on 27 May 2009 at 2:43

[GoogleCodeExporter]

The initial idea behind this RFE is this:
http://code.google.com/p/modmemcachecache/wiki/README

Original comment by skar...@gmail.com on 27 May 2009 at 3:07

[GoogleCodeExporter]

skarcha, I was told by alobbs to post here what I wrote in the irc channel ;)
Think this is now discussion for overall memory caching implementation in 
cherokee.

Original comment by michael....@gmail.com on 27 May 2009 at 3:11

[GoogleCodeExporter]

To see what binbash and I mean just follow this link:

http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/

Original comment by umschlag...@gmail.com on 1 Jul 2009 at 2:46

[GoogleCodeExporter]

But this is again not what binbash was suggesting ;) Because as I mentioned 
before
that implementation is trivial. It basically consist of a fetch only component 
!=
mod_memcache.

If indeed *this* is what you want, binbash should have said yes to his private 
email ;)

Original comment by ste...@konink.de on 1 Jul 2009 at 4:34

[GoogleCodeExporter]

Well this would make my special request obsolete, because what Patrick posted 
is more
efficient.

Original comment by michael....@gmail.com on 1 Jul 2009 at 5:01

[GoogleCodeExporter]

Don't know if it is somewhere but this code could be used to get memcache inside
Cherokee. There is a bug with keepalive we should still fix.

Original comment by ste...@konink.de on 7 Sep 2009 at 12:36

Attachments:

• memcached-update.diff

[GoogleCodeExporter]

Original comment by ste...@konink.de on 7 Sep 2009 at 12:36

• Changed state: Started

[GoogleCodeExporter]

Is the web interface .py fixed in this patch? Don't think so??

Original comment by michael....@gmail.com on 7 Sep 2009 at 7:34

[GoogleCodeExporter]

Webinterface still broken.

Original comment by ste...@konink.de on 7 Sep 2009 at 8:19

[GoogleCodeExporter]

Would love to see this integration completed :)

Any update on progress?

Original comment by kiall%ma...@gtempaccount.com on 13 Feb 2010 at 9:38

[GoogleCodeExporter]

Still waiting why there is a huge performance penalty on any non-match.

Original comment by ste...@konink.de on 13 Feb 2010 at 9:42

[GoogleCodeExporter]

Is someone working on this feature currently?

What are the preliminary numbers - time comparing a match found versus a match 
not
found in milliseconds?  How does this compare with performance of Cherokee 
doing this
on it's own absent any memcached?

This feature would be useful for anyone running multiple Cherokee instances for
scaling and redundancy.

Original comment by pubcrawl...@gmail.com on 13 Feb 2010 at 9:54

[GoogleCodeExporter]

Alo suggested to take an extension match and make it never match the thing, and 
not 
disable it, but always make the thing match. In that way you can test it.

Original comment by ste...@konink.de on 13 Feb 2010 at 10:10