Memory is not going to cut it. Your 'instances' are put up and torn down all the time. So while instance memory might work for short term caching, you can't rely on it. *
If you can live with occasional losses, just use memcache incr() - memcache can still loose data** http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/memcache/MemcacheService.html#increment(java.lang.Object, long) Then have periodic tasks, that 'writes' the value from memcache into the datastore. * Unless you use backends. They are resident, and less likly to suffer memory loss. But in general from what I understand backends wouldnt be a good fit to implement the actual API serving. ** But if you experience regular data loss, just increase the frequency of tasks. On Mon, Aug 22, 2011 at 5:33 PM, mikegleasonjr <[email protected]> wrote: > Hi, > > I'm designing an app which provides a service. Like a public API > exposed to the world. > > Ppl are able to use my service via the API. So one call to my app is > an API call. Every calls are read only calls to the datastore. > > I want to track each API call (have the total count of API calls for > each account). My business model revolves around the API usage by its > members. So when a client makes an API call, I increment the call > count in its entity. I want to follow the principle that if you're > using the API more, you will pay more. I want to follow that App > Engine philosophy regarding the business model. > > But It seems a little hard on the HRD, to do a 'put' on an entity for > every API call. > > What I can live with is an alternative solution: Maybe I can have an > application-wide dictionary that keeps tracks of the call counts in > memory, and that would flush its counts to the datastore every hour > (via a cron job). The worst that could happen is that I would loose an > hour of API usage if there's a downtime. I can live with that. > > I'm pretty new to java, and considering the nature of the distributed > environment, what would be your strategy for implementing such a > behavior? I guess a dictionary for each web server instance in memory > would work anyway, they would each increment the API calls count every > hour to the datastore. > > So a cron job would be necessary, and a locking mechanism when > accessing this global dictionary. > > Maybe HDR is fast enough to sustain one of my client which can make > max 100 API calls / sec. But also I want the app to use as little > resources as possible to keep the costs down for my clients and the > speed up :) > > What are your ideas!? > > 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. > > -- 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.
