Interesting analysis, really appreciate it. Some responses to your points: - I'm looking at some other examples of the stats and I don't have that big break between get/set, so I'm thinking that's a one-time thing. Going to continue looking at the code to see if I can find that what could have been. - I unfortunately can't combine the gets, they are all doing different things in different places, but I'll dig deeper and maybe find some opportunities. - I'll definitely post any answer I get to this here.
Thanks again for the advice...hopefully someone from Google gives us some insight On Jun 27, 6:13 pm, Luís Marques <[email protected]> wrote: > Hi Lenny, > > If you find the answer to this one please post it here, since it seems > quite a few interesting questions go unanswered in this group. > > I'm no expert on this matter, but there's something hard to understand > indeed. The CPU cost (without API) makes sense if you think about the > following. In the middle of the graph, between 20 ms / 21 ms get / set > memcache calls there is a gap, about 600 ms in length. That is your > could executing, without RPCs, so that explains about 0.6s of the 2s > of CPU usage. Presumably, the remaining 1.4s would be code executing > after the last memcache get RPC, and so wouldn't be visible on the > timeline (perhaps you've got something slow there?). > > Now, what doesn't make sense to me is the CPU + API grand total. There > are 66 ms of RPC API summed up at the RPC total. That makes sense, > it's the two datastore calls, a get and a query. But where does the > remaining API time come from? I thought API times only came from RPC > calls. It seems something else must be responsible for that. I'm > curious what. > > BTW, can't you merge the memcache gets, sets and deletes in only three > RPC calls? E.g. memcache.get_multi()? > > On Jun 27, 11:54 pm, Lenny Rachitsky <[email protected]> wrote: > > > > > I'm having trouble understanding where the usage costs are coming > > from, specifically arround the CPU/API usage. I'm looking at the > > following app stats example: > > >http://img.skitch.com/20100627-x6s7s988y2kg2at3kg3t6984ig.png > > > To me this looks rather well optimized, except when you get to the > > "Grand Total" which has a huge cpu+api cost. Can anyone help me > > understand what could be causing this? My costs are growing quickly, > > and I'm considering some major revamping to deal with this situtation > > I can't explain. > > > Any help would be much appreaciated, > > Lenny -- 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.
