Satoshi, thanks very much for the detailed description. That certainly gives me something to think about.
I assume in your social network, there are a lot of parts of the display that are common to all users. In my case, a given user's page bears no resemblance to another user's page (other than the banner at the top) since it's basically a list of photos. So I'm not sure if the technique would work for me. BTW it sounds like you will get several requests (via AJAX) per page viewed, so I guess that drives up your request count? About memcache not helping much for customized output, I hear what you're saying, but I can at least use it to avoid hitting the datastore multiple times as a given user browses around. That's why I'm thinking I'd like to have the memcached data around for 10 minutes on the assumption that they will hang around that long. But after that 10 minutes, their cached data would just be competing for space with that of other users which is why I'm thinking of limiting its duration. And wondering if putting a 10-minute limit is going to help that situation. Thanks again! On Jan 6, 6:26 pm, Satoshi <[email protected]> wrote: > It probably depends on the type of application, but memcache does not > help you much if you have a lot of customized output (which are > different > from one user to another). > > My application (social network application) has a very similar > requirement, > and I am solving this problem by doing following: > > 1. Break the data into pieces, so that each data is identical to all > the users, > 2. Assign a unique URL to each data, and cache them in memcache using > the URL as the key, > 3. Write some JavaScript code on the client side and construct the > custom page > by retrieving those data using AJAX (typically in JSON format, but you > can use HTML-let as well). > > In other word, the server side of code is mostly acting as Model (in > MVC), and > the JavaScript code on the client side is acting as Controller. > > I found that this architecture works really well with App Engine and > memcache, allowing me > to keep the cache hit rate very high (>95%) and the average access > time to below 100 cpu_ms. > > By the way, please aware that you still need to put some access > control on the server side (above memcache). > For example, the "profile of each user" can be accessed via "http:// > myapp.appspot.com/profile?uid={user_id}" > (which can be cached in memcache), you want to make it sure that only > friends can access that profile. > > Satoshi > > On Jan 5, 1:21 pm, dburns <[email protected]> wrote: > > > My app may display a lot of different output for a given page > > (customized per user amongst other things), and I'm wondering how best > > to use memcache. > > > My current scheme is to estimate that a given user's output might be > > useful for, say 10 minutes, after which time the user has probably > > gone away so there's no point caching it. It's not that the content > > is invalid after 10 minutes (I explicitly clear memcache if content > > becomes invalid). Rather, I'm trying to aid memcache in determining > > what it can get rid of. > > > Is this a good idea, or am I interfering with memcache's algorithm? > > It may all depend on the exact details of the application, but I'm > > wondering if there any general advice on memcache usage. > > > Thanks. > >
-- You received this message because you are subscribed to the Google Groups "Google App Engine" 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?hl=en.
