Hi Richard, This occurs because the dev_appserver is single-threaded, and so the SDK implementation of the Channel API can't get any data until the task finishes executing.
Why do you want to spend time waiting in a task? Why not kick off a new task when you get new data from the user, send the appropriate messages, then quit? -Nick Johnson On Fri, Jan 21, 2011 at 1:47 AM, Richard Arrano <[email protected]>wrote: > Thanks for the info Nick and Robert; I actually have been using that > exact talk to tweak my app and it's been extremely useful. > > One more thing I wanted to ask: the way I've been structuring the > auction type setup is through a Task object that creates a custom > class I've built that basically follows this pattern: > > while auction.notFinished(): > <do auction work> > send updates to users in the auction via channel.send_message > time.sleep(0.5) > > For initial development I've just set notFinished() to check against a > counter within the class that increments up to some arbitrary number > like 50. I've set the user page to connect to the channel, and it does > receive messages but it only receives them after the while loop > terminates. This is being run in a task and NOT in the handler for the > page being served. This perplexed me - I tested it on the actual > servers and it doesn't suffer this problem, but it is still very very > laggy - I set it to send back a user's message sent to the channel and > it takes quite a few iterations of the loop to print this. Is there a > better way to structure this? > > Thanks, > Richard Arrano > > On Jan 16, 7:14 pm, "Nick Johnson (Google)" <[email protected]> > wrote: > > Hi Richard, > > > > On Sat, Jan 15, 2011 at 12:05 PM, Richard Arrano <[email protected] > >wrote: > > > > > Thanks for the response! I was thinking it over and I have a question > > > - so if a timestamp with its monotonically increasing index causes a > > > performance hit at a high write rate, would updating the high bid do > > > so as well ? The high bid itself will be monotonically increasing - it > > > will never go down, but perhaps I misunderstood something about how > > > indices work. > > > > See the reply I just sent - while it's true that something like the > > increasing bid would cause the same issue, it's not going to be a problem > at > > the sort of write rate you're likely to see here. > > > > > > > > > And I guess a broader question that I have is(and I assume the answer > > > is yes) - does the size of what we're writing affect the performance? > > > As in, writing a simple update to an integer property as opposed to > > > creating new complex objects and writing them. > > > > To a small degree, yes, the size of the object will affect the overhead, > but > > it's not the largest factor - other things like the number of index rows > you > > have per entity will have a much bigger impact. Note that the size that's > > significant is the size of your whole entity, not the amount of data > you're > > changing. > > > > -Nick Johnson > > > > > > > > > Thanks, > > > Richard > > > > > On Jan 14, 10:05 am, "Ikai Lan (Google)" > > > <[email protected]<ikai.l%[email protected]> > <ikai.l%[email protected] <ikai.l%[email protected]>> > > > > > wrote: > > > > You can certainly write to Memcache, but I don't think your > application > > > can > > > > tolerate any kind of volatility. Persistence is the price you have to > > > pay. > > > > Fortunately, I think this can be done pretty cheaply. Just be aware > of > > > > monotonically increasing indexes like timestamps: if you have an > > > application > > > > with a high write rate that has a timestamp, this will cause the > > > persistence > > > > unit storing the indexes to be unable to be autosplit easily across > > > multiple > > > > hardware instances and you will take a performance hit. The solution > here > > > > is, again, to shard the timestamp by prefixing a value to distribute > the > > > > writes. > > > > > > -- > > > > Ikai Lan > > > > Developer Programs Engineer, Google App Engine > > > > Blogger:http://googleappengine.blogspot.com > > > > Reddit:http://www.reddit.com/r/appengine > > > > Twitter:http://twitter.com/app_engine > > > > > > On Fri, Jan 14, 2011 at 6:06 AM, Richard Arrano < > [email protected] > > > >wrote: > > > > > > > I'm looking to make a silent-auction type of application where you > > > > > have 20-30 users bidding on an item at a time, with potentially > > > > > hundreds or thousands of auctions happening simultaneously. As soon > as > > > > > a high bid is made, it updates this information and sends it via > the > > > > > Channel API to the other users in the auction. I see two potential > > > > > difficulties: > > > > > > > 1. The limit on updating an entity group about once per second - > I > > > > > believe this can be solved with sharding bids amongst users in the > > > > > auction and querying all shards to find the maximum bid at any > given > > > > > time, correct? > > > > > > > 2. The nature of the auction lends itself to a heavy amount of > > > > > writing to the datastore - this itself eats up CPU and I’m trying > to > > > > > figure out if it can be avoided. Is this just inevitable in this > type > > > > > of application? Does it matter that I would only be only updating a > > > > > single IntegerProperty() in any given write? Is there some clever > > > > > solution that we can apply that avoids the hammering of the > datastore? > > > > > > > Any tips or suggestions would be appreciated. > > > > > > > Thank you, > > > > > Richard > > > > > > > -- > > > > > 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]<google-appengine%[email protected]> > <google-appengine%[email protected]<google-appengine%[email protected]> > > > > > <google-appengine%[email protected]<google-appengine%[email protected]> > <google-appengine%[email protected]<google-appengine%[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]<google-appengine%[email protected]> > <google-appengine%[email protected]<google-appengine%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine?hl=en. > > > > -- > > Nick Johnson, Developer Programs Engineer, App Engine > > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration > Number: > > 368047 > > -- > 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]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- 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.
