There is a good chance the gains you saw are due to improved batching. The other gains are probably from async, ie you being able to prepare the data for your next put or fetch more data rather than waiting around. If you're using Java, could also be multithreading gains.
As Jeff said, all RPCs are flushed when your request handler returns. On Tue, Jan 31, 2012 at 19:43, James X Nelson <[email protected]> wrote: > Async everything will always save you instance hours. It doesn't matter if > you are threadsafe or not, the async operations allow you to perform a ds / > memcahce / url fetch in a background thread, which you can check on whenever > you want. > > Async is extremely useful if you use it to perform "datastore streaming"; if > you have to operate on thousands of entities, you can cut your runtime from > "all of the time to create and persist all of the entities" to "all of the > time to create all of the entities, and little to no time waiting for ds > operations to complete". I use a helper object to stream all my writes, > deletes and reads in async batches, with custom page sizing. The helper > holds the entities in memory, async puts() them in batches when the page > size is reached, and holds the entities in memory until their put() > succeeds, so it can retry anything that fails. Another easy way to retry a > future, at least in Java, is to create a subclass of Future<Entity> that > takes the Entity as a param, wraps the appengine Future<Key>, and > automatically retries in transient errors. For retry, I use synchronous > rather than async again, but you can do whatever you like. > > Using async everywhere, with threadsafe, got our app down from $30/day for > frontend instance hours to ~$0/day for frontend instance hours. We > generally have 4-6 live instances, but only use approximately 1 instance > hour / hour. > The trick is that all your api operations can happen in the background, so > your total processing time is near or equal to your "userland" processing > only. > > PS - Anyone that doesn't actually call .get() on their futures to finalize > your async operations could lose data, especially if the last operation in > your method is an async put. Async operations started by your current > processing thread die when the thread returns {in production}, so make sure > you call .get() on the returned future. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/hK5rhcibQ1oJ. > > 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.
