Here's the relevant ops that one of these pages (ex:
http://www.nmaps.net/172547) does:
self.user = model.User.get(db.Key(self.session['user']))
map = model.Map.get_by_map_id(int(map_id))
q = model.Comment.all().ancestor(map).order("-lastupdated")
comments = q.fetch(COMMENTS_PER_PAGE + 1)
q = model.Map.all()
q.filter("user =", map.user)
q.filter("unlisted =", False)
q.filter("float_num <", map.float_num)
q.order("-float_num")
other_maps = q.fetch(6)
As you can see, typically two gets for a single entity, along with a
couple of queries - one for up to 40 entities (COMMENTS_PER_PAGE=40),
one for 6.
-Nick Johnson
On Fri, Jul 10, 2009 at 5:09 PM, Alex
Popescu<[email protected]> wrote:
>
> Hi Nick,
>
> I'll deploy some tests to further investigate this issue and I'll
> provide the code and results.
>
> Meanwhile, I'm wondering if you could share the relevant pieces of
> code in your app that are tipically
> below 600ms. I must confess that I haven't seen many such cases in my
> app so far
> (except some on which I'm doing extremely aggressive caching).
>
> ./alex
> --
> .w( the_mindstorm )p.
> Alexandru Popescu
>
>
>
> On Jul 10, 2:46 pm, "Nick Johnson (Google)" <[email protected]>
> wrote:
>> Hi Alex,
>>
>> It's impossible to give a useful comment without first seeing the code
>> that you're using. Speaking from my own experience, I have a personal
>> site that serves reasonably datastore-intensive pages, and typically
>> total CPU milliseconds doesn't exceed about 600 - that's to do several
>> get requests and at least one query. So it's certainly possible to do
>> useful work with the datastore and come in well below the 1300 to
>> 1400ms you quote.
>>
>> -Nick Johnson
>>
>> On Fri, Jul 10, 2009 at 1:27 AM, Alex
>>
>>
>>
>>
>>
>> Popescu<[email protected]> wrote:
>>
>> > Hi guys,
>>
>> > I have a cron op that is fetching some records for an entity and does
>> > some processing on them.
>>
>> > While checking my app logs I have noticed that for the trivial case
>> > when no result is returned (and so there is no additional processing
>> > done) this operation is billed constantly with something between
>> > 1300ms and 1400ms.
>>
>> > This basically tells me that this is the initial cost of a roundtrip
>> > to the datastore (plus basic request dispatching; note: the response
>> > doesn't have any data).
>>
>> > Based on this I can further deduce that on a daily basis the free CPU
>> > quota will allow me to run around 18k datastore roundtrips with 0
>> > results.
>>
>> > How do you comment on this data when compared with the public
>> > announcements you've done in the past about the amount of requests an
>> > app can serve based only on free quota?
>>
>> > ./alex
>> > --
>> > .w( the_mindstorm )p.
>> > Alexandru Popescu
>>
>> > PS: I have argued (and I continue to believe) that billing for CPU
>> > time is completely incorrect to app engine customers and that Google
>> > should look into some alternative options:
>> >http://themindstorms.blogspot.com/2009/06/open-letter-to-google-app-e...
>>
>> --
>> Nick Johnson, App Engine Developer Programs Engineer
>> Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration
>> Number: 368047
> >
>
--
Nick Johnson, App Engine Developer Programs Engineer
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
-~----------~----~----~----~------~----~------~--~---
