I actually use it solely to cache API responses. It cut down the response times from 800 ms --> 50 ms. Plus it also ensures my API partners are kept happy. :)
On Wed, Jul 6, 2011 at 12:52 AM, Stefan de Konink <[email protected]> wrote: > In that case you favorite database shpuld implement caching, my favorite > database already does. > > The strengt of memcache is not in caching a database, but cache generated > pieces of content. > > Stefan > > Op 6 jul 2011 om 09:35 heeft James Isaacs <[email protected]> het > volgende geschreven:\ > > That's what I was initially thinking, but after some more thought, it >> makes a lot of sense to use that sort of handler and expanding on it >> for use with the MySQL or another database bridge. >> >> Memcached could be used to cache query results, serving results from >> Memcached where they have already been set, and the handler could know >> when db modifications should delete specific keys from Memcached. This >> is a familiar design for many web applications already, so essentially >> it could result in a well performant 'out of the box' web API. >> >> >> On Wed, Jul 6, 2011 at 12:27 AM, Stefan de Konink <[email protected]> >> wrote: >> >>> On Wed, 6 Jul 2011, James Isaacs wrote: >>> >>> I actually retract what I said. Memcached is really for the >>>> application layer between the database and your choice of CGI. This is >>>> something unique to most platforms, so... I'm not really sure how a >>>> web server can handle this with a common interface. >>>> >>> >>> As you can see in the bugtracker. I implemented a handler that allows to >>> serve memcached content. Based on the content being present in memcached, >>> otherwise it would be generated. But this usecase is similar to the >>> front-line cache. >>> >>> Stefan >>> >>> >> !DSPAM:1,**4e14104725081785578686! >> >>
_______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
