One thing I dont understand is, if one runs python2.7 with thread safe enabled, why would this reduce instance hours? Wouldn't the instance just handle other tasks until the non-async rpc is complete? Or is a sync rpc blocking the instance from handling another request (would surprise me)? I'm assuming one has a lot of requests.
(Left aside the RAM & Latency optimization one would get) Cheers, -Andrin On Wed, Feb 1, 2012 at 7:25 PM, Brandon Wirtz <[email protected]> wrote: > I got deferred working. Missed that you have to enable it as a built in, > which I chalk up as I shouldn't code when people are out of office and I'm > tired. > > The result seems to be pretty awesome. Not waiting for writes speeds us > up, > and pacing the tasks evens out the peaks and valleys of our instance use. > > I don't think we will save actual CPU hours, but by filling the valleys and > delaying the peaks we should use fewer instance hours. > > The biggest thing I learned... Don't walk away when debugging 5 QPS spawned > 1 task per second, which when it threw and error resulted in more tasks > piling up and more instances... it would be expensive if I had just > wandered > off. > > Brandon Wirtz > BlackWaterOps: President / Lead Mercenary > > Work: 510-992-6548 > Toll Free: 866-400-4536 > IM: [email protected] (Google Talk) > Skype: drakegreene > YouTube: BlackWaterOpsDotCom > > BlackWater Ops > > Cloud On A String Mastermind Group > > > > > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Robert Kluin > Sent: Tuesday, January 31, 2012 11:10 PM > To: [email protected] > Subject: Re: [google-appengine] Re: Put_Async Use It > > 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. > > > > -- > 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.
