[FoRK] overhead of RESTful stuff
lisa at rtfm.com
Thu Mar 8 10:44:58 PST 2012
Yep, I agree that caching at two different levels can be useful. Once with
HTTP caching rules, and again with memcached.
Typically, I think, with an AJAX REST app, the data request is
> essentially tunneled through the web server in a way that is hard for it to
> cache. It's conceivable to have app server capability to invalidate web
> cache items, and some web proxies like Squid have extensive protocols, but
> I don't think anyone does it now.
In the systems I've used -- java servlets, Python and django, ruby and
rails -- the data request ought not to be tunneled through in any way that
is hard for a cache to be in front. I guess one might set it up that way
in some situations but I'm not clear why. If you've seen this, I would be
interested in understanding the situation a little better.
The cache invalidation problem (and like you, I'd like to see more
functionality to let people make use of this, but it is not commonly used)
is why data/resource design is the most important performance work. If
there's any information in an app that can be publicly shared, then there's
usually some way to cache that in a way that it can be re-used without
getting too stale. Perfection is the enemy here, if data can be just a
little bit stale, or if there are correction mechanisms for fixing stale
public data if the user shows clear interest in a data point. E.g. if "top
ten user contributions by number of votes" is cached and gets ten minutes
stale, and somebody looks at the item with 99 votes and clicks on it to see
it really has a hundred, there's both a tolerance for staleness and a
There are also very commonly tradeoffs between size of response and
cacheability. E.g. if some users view a public set of resources including
the date field and others dont, some view the size field and others don't,
some view the full title and some view a truncated title, some view the
creation date and some don't, well who cares -- just shove all the values
in the response and cache it.
More information about the FoRK