Asynchronous memcache?
61 views
Skip to first unread message
Joel
Jul 9, 2008, 10:12:28 AM7/9/08
to Google App Engine
Does anyone think it would be useful to have the ability to perform
memcache set and delete asynchronously? That is, the call to set
would return immediately and the actual setting would occur
asychronously; same for delete.
In some cases I'd find it reasonable to be optimistic about the
memcache being set in time before the next request that accesses it.
This would allow my app to respond faster.
The CPU usage of the asynchronous setting could still be charged to my
account.
Or is this just silly?
Joel
memcache set and delete asynchronously? That is, the call to set
would return immediately and the actual setting would occur
asychronously; same for delete.
In some cases I'd find it reasonable to be optimistic about the
memcache being set in time before the next request that accesses it.
This would allow my app to respond faster.
The CPU usage of the asynchronous setting could still be charged to my
account.
Or is this just silly?
Joel
ryan
Jul 9, 2008, 10:53:52 AM7/9/08
to Google App Engine
one difficulty with this would be error handling. if the memcache set
or delete fails, but you've already returned a response for the HTTP
request, you have no way of handling the failure. that might be ok for
sets, assuming you're using memcache as just a cache, but it seems
like a failed delete would be a problem. future requests would still
see that data in the cache, even though it shouldn't be there any more.
or delete fails, but you've already returned a response for the HTTP
request, you have no way of handling the failure. that might be ok for
sets, assuming you're using memcache as just a cache, but it seems
like a failed delete would be a problem. future requests would still
see that data in the cache, even though it shouldn't be there any more.
ryan
Jul 9, 2008, 10:57:54 AM7/9/08
to Google App Engine
also, i'm seeing latencies for memcache operations in the .5 to 1.5 ms
range. that's really fast. unless you're doing a *lot* of memcache
operations in a single HTTP request, i doubt async support for
memcache would make a noticeable difference. on the other hand, async
support for other APIs with higher latencies, e.g. the datastore and
urlfetch, would have a much greater impact.
range. that's really fast. unless you're doing a *lot* of memcache
operations in a single HTTP request, i doubt async support for
memcache would make a noticeable difference. on the other hand, async
support for other APIs with higher latencies, e.g. the datastore and
urlfetch, would have a much greater impact.
Joel
Jul 9, 2008, 12:18:05 PM7/9/08
to Google App Engine
Yeah, I agree that memcache itself is fast.
I'm trying to avoid waiting for the pickling of my data :-)
Agreed that if a set fails it should just mean that you get it from
the datastore next time you try to retrieve it. But if there was a
previous set, would that older version still exist in which case I'd
be seeing bad data. Hmmm.
I can see delete being a problem. In my case I'm using memcache as a
cache and I'm simply trying to clean it up. But since I don't need to
worry about pickling in the delete case (or so I think) then that
isn't a problem.
Perhaps an asynchronous set could have the semantics of set or delete
if error?
(Getting too complicated most likely...)
I'm trying to avoid waiting for the pickling of my data :-)
Agreed that if a set fails it should just mean that you get it from
the datastore next time you try to retrieve it. But if there was a
previous set, would that older version still exist in which case I'd
be seeing bad data. Hmmm.
I can see delete being a problem. In my case I'm using memcache as a
cache and I'm simply trying to clean it up. But since I don't need to
worry about pickling in the delete case (or so I think) then that
isn't a problem.
Perhaps an asynchronous set could have the semantics of set or delete
if error?
(Getting too complicated most likely...)
Reply all
Reply to author
Forward
0 new messages