good chat! sorry i missed it. i have a few comments, inline:

On Mar 5, 11:27 am, Marzia Niccolai <[email protected]> wrote:
> [7:05pm] amichail: How to fix an index that is stuck on "Building"?
...
> [7:06pm] marzia_google: if an index has been in building more than 24 hours
> you will need to send an email to the group and someone will be able to fix
> it

more info:

http://code.google.com/appengine/articles/index_building.html
http://code.google.com/appengine/docs/python/datastore/queriesandindexes.html#Big_Entities_and_Exploding_Indexes

> [7:19pm] Kardax: Ok, next question: we have db.run_in_transaction; is there
> a chance of getting a db.run_in_snapshot?
> [7:20pm] Kardax: I'd like to be able to read an entity group from a
> consistant state without the overhead of a transaction.

db.run_in_transaction() actually adds very little extra overhead. for
read-only transactions, all it adds is a single disk seek to read the
timestamp of the entity group's log header. that read will always be
smaller than any of get(), and more importantly for latency, it's only
a single disk seek, as opposed to queries, which take multiple disk
seeks.

given that, i'd recommend using db.run_in_transaction(). you should
only see minimal performance impact.

> [7:19pm] dankles: Q: What (if any) progress / plans are there on reducing
> Datastore CPU usage?
> [7:22pm] marzia_google: @dankles there isn't anything specific to report wrt
> to datastore cpu

we've actually made a number of solid improvements to datastore CPU in
the last couple months, both to how much CPU we actually use and to
the accuracy of our measurements.

having said that, one useful thing to note is that CPU is a broad
category. along with pure CPU, it also includes the cost of disk
accesses, particularly disk seeks, which are slow (relative to pure
CPU and in-memory operations) and expensive.

> [7:27pm] dankles: Q: Not sure if this has come up... Any plans to
> offer/parter with CDN, so a few lines in app.yaml could push a directory of
> static assets out for efficient serving?
...
> [7:30pm] dankles: @angerman: but GAE isn't really well suited for being a
> CDN
> [7:33pm] dankles: @angerman : a good CDN has servers all over the world,
> serving each user from the closest edge, and optimized for low bandwidth
> costs, static assets... GAE design goals were different, as it clusters
> around itself + Datastore, etc.

that's true for serving dynamic requests, but static files aren't
subject to those constraints. you'll probably find that static files
served through app engine are already fairly efficient and low
latency, regardless of where you are in the world, and we expect that
to get even better in the future.

of course, no need to take our word for it. you can always measure
yourself and compare to other CDNs, or look at a few of the blog posts
and threads on the group that have already done that.

> [7:35pm] Kardax: Another question:  How "big" can an entity group be before
> problems are encountered (besides concurrency)?  What's the definitiion of
> "big"?  What problems are seen?
> [7:36pm] marzia_google: with entity groups, the biggest issues is contention
> [7:36pm] marzia_google: since writes to an entity group happen serially
> [7:37pm] marzia_google: so an entity group is too 'big', i would say, when
> it can't reasonably handle the number of writes to the group
...
> [7:38pm] Kardax: I'm more concerned with physical size limitations... for
> example, if I can make reasonably sure that contention will be low, but it
> could have 10's of thousands of entities in size, is that going to work?

marzia's absolutely right here. there isn't really any meaningful
limit to entity group size, either bytes or number of entities. the
main thing entity groups limit is write throughput, not size.

> [7:55pm] angerman: marzia_google: could you publish a list of
> "successfull"/high traffic app-engine apps?

definitely! http://code.google.com/appengine/casestudies.html

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to