Datastore gets also cost us a lot. The thing we have discussed doing, but have not done yet, is put some instrumentation into the pre-call hook [1] to count the entities involved in query and gets. This would allow us to "slice" the data by entity, app engine service, and if you added stack trace sampling, by caller. If you try something like this, I would be very interested in hearing how it works! Good luck,
Evan [1] http://blog.notdot.net/2009/11/API-call-hooks-for-fun-and-profit On Monday, December 12, 2016 at 5:48:07 AM UTC-5, Mark Cummins wrote: > > Hi, > > One day last week our Datastore Read Operations were 5x their normal > level, and we're trying to identify why. > > The problem is almost certainly caused by some corner case in our own > code. My question is, how can we go about identifying what caused this > issue? > > As far as I can see, our only way to keep track of Datastore Reads is via > the billing page ("View Usage History"), which shows the total number of > reads on a given day (and there is about a 2 day delay before the report is > ready). Is there any way we can get more precise information about what > caused our spike in Datastore Reads? If we could narrow it down to a > particular handler, or even a particular time of day, we could sort it out > pretty quickly. The main dashboard at least gives you a graph of memcache > usage by time of day, but nothing for Datastore Reads that I can see? > > Thanks, > Mark > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/0bad7c07-3cc0-4ad0-8d1a-00370678bcaa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
