I did my own tests on api_cpu cost for meModel.get_by_key_name() versus
db.GqlQuery("Select * From meModel Where value=:1",meValue).fetch(1)
It costs a fixed 2.6 times as much to do the GqlQuery (it seems Google has
pegged the api_cpu cost of these queries to a set amount. 10 for
.get_by_key_name() and 26 for .fetch(1)). And.. if you are beyond the free
quota and paying for CPU.. then this will indeed cost 2.6 times as much
money to do the .fetch(1) versus the .get_by_key_name(mykey).
I guess if you aren't using a lot of api_cpu.. then it won't matter.
It also seems that .get_by_key_name() can be twice as fast at times.. but it
isn't consistent. And really.. the time taken is fairly equivalent (as you
have noted).
The primary benefit, I can see, in using .get_by_key_name() is when setting
an entities key_name = to a composite of two of it's values (that will
remain fixed). This allows you to forgoe setting up a composite index,
which would slow down puts and also take up storage space.
I use a model likes so:
class myModel(db.Model):
ID = db.IntegerProperty(required=True)
step = db.IntegerProperty(required=True)
quote = db.FloatProperty(required=True,indexed=False)
and I put the entities like so:
meEntity = myModel(key_name = str(myID)+"_"+str(mystep),ID=myID,step=mystep,
quote=myQuote)
db.put(meEntity)
so.. if I want the entity where ID = 1 and step = 3402.. i just
.get_by_key_name("1_3402") instead of needing an index defined on (ID,step).
If I want a bunch of them in a range, I precompute the keys into a list and
do .get_by_key_name() on that list.
Anyway, everyone should do whatever balances performance with development
time in the way that best suits them.
On Wed, Feb 10, 2010 at 12:49 PM, Waldemar Kornewald
<[email protected]>wrote:
> On Feb 10, 6:11 pm, Eli Jones <[email protected]> wrote:
> > The main difference I find in .get_by_key_name() is the CPU overhead..
> not
> > the time it takes. So .. you should also be benchmarking API CPU time
>
> Yes, here the individual fetch() calls indeed cost more than 2x as
> much, but really I'd rather pay slightly more (it won't be 2x as much,
> anyway, when taking all queries and other cost factors into account)
> and not care about the productivity overhead that keys add. In
> benchmarks I did a pretty long time ago (when App Engine was very
> young) a single get() took around 17ms and a fetch() for a single
> entity could take 35-90ms, depending on how lucky you were. This was
> significant enough to be noticeable on some pages which loaded a lot
> of individual entities, so we accepted that, for example, usernames
> can't be easily modified afterwards. The new numbers totally change
> the game.
>
> Hopefully, someday we'll also not have to care about startup times,
> anymore (even if we have to pay a few $/month for pre-warmed instances
> or give up the free quota for warm instances).
>
> Bye,
> Waldemar
>
> --
> 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.
>
>
--
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.
