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]>
>
> > 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]>
>
> > > > .
> > > > 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]>
> > .
> > 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.
