Hi Toby,
I made some code public that does what you describe: it is a simple
cache interface that has implementations for in-memory, memcache and
the datastore. You get about 100MB of heap space to use which can
significantly speed up your caching.
There is also a CompositeCache class that allows you to layer the
caches so that it first checks in-memory, then memcache , then the
datastore. Puts go to all levels and cache hits refresh the higher
levels. e.g. if an item is not in-memory and has been flushed from
memcache but is still present in the datastore then the other two will
be updated.
http://code.google.com/p/stick-cache/
Hope this helps,
John
On 18 Jun 2010, at 15:08, Toby wrote:
Hello Ikai,
Sorry but I might have worded my post incorrectly. I do not doubt
memcache, in fact I use it very heavily and it is great.
On Google I/O I learned that memcache is actually hosted on another
machine and that for each request a significant network overhead is
involved. In appstats I see about 20ms for a single request. Simple
data-store requests are also between 20-50ms. So in fact memcache is
good as second level cache but shows to be a bottleneck for data that
I heavily use over and over again (plus it costs valuable API time).
So the idea was to have some "first level" in-memory cache living on
the same machine that is holding heavily used data to prevent the
server round trip to the cache machine. Now you might tell me that my
application is designed wrong. And indeed I could just put this in by
myself. But as you also pointed out there are tricky parts like memory
boundaries and other things to take care of. This is why I started
this thread to see if someone has come up with a good solution.
I think multiple cache layers are kind of a standard approach that has
shown its usefulness in many places. It would be good to have that as
part of GAE. Of course this is not the most urgent issue.
Cheers,
Toby
On Jun 17, 6:46 pm, "Ikai L (Google)" <[email protected]> wrote:
What aspect of Memcache is too slow? Have you run AppStats yet?
The overhead of Memcache is low enough for many of the top sites on
the
internet to use. Some sites are listed on the main page here:
http://memcached.org/
As you move closer and closer to local memory, the volatility of
your cache
will increase, so the only items I would store in local memory are
items
that are okay to lose. If you want, you can probably layer your
application
to fetch from memcache -> fetch from authoritative source and place
into
local memory on a cache miss. Just be aware that there are process
memory
limits, and exceeding these will force a restart.
On Thu, Jun 17, 2010 at 2:30 AM, Toby <[email protected]> wrote:
Hello,
I wonder if there is a framework (such as Objectify) also for
memcache. As memcache is not on the local machine it is rather
slow,
especially for reoccurring requests. So on Google I/O they suggested
to build your own in-memory layer around that. I know that is an
easy
task, still I wonder if there might already be a framework for
that :-)
Also I wonder if someone can give me some ideas about how to build
an
in-memory cache. I guess it is just a static hashmap. But will it
survive multiple requests? How much can I put in there?
As the problem of memcache is apparently the high latency for the
network traffic to the server I had the idea to store the in-memory
cache in the memcache, de-serialize it and then use it?
Do you have other ideas how to speed up caching?
Thank you for your advice,
Toby
--
You received this message because you are subscribed to the Google
Groups
"Google App Engine for Java" group.
To post to this group, send email to
[email protected].
To unsubscribe from this group, send email to
[email protected]<google-appengine-java%[email protected]
>
.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
--
Ikai Lan
Developer Programs Engineer, Google App Engine
Blog:http://googleappengine.blogspot.com
Twitter:http://twitter.com/app_engine
Reddit:http://www.reddit.com/r/appengine
--
You received this message because you are subscribed to the Google
Groups "Google App Engine for Java" group.
To post to this group, send email to [email protected]
.
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en
.
--
You received this message because you are subscribed to the Google Groups "Google
App Engine for Java" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
